How to query the GstSegment "rate"?

[Andy Robinson]

GST 1.2.4 and subsequent, Windows, Mac, Linux.

I am using gst programmatically to play video.

I have a video (produced by other software) which was produced by
slowing down a clip of originally 30 secs so now it plays for 60 secs,
no problem, in GStreamer and QuickTime Player.

I find that it has a GstSegment specifying a "rate" of 0.5, so that is
how the other software did the slowdown.

I find that when I want to seek using gst_element_seek_simple within
this video I must use the pre-slowdown times, e.g. if I want to seek to
the 40th second of the 60 second video, I must actually seek to a time
of 20 secs, and also must make a similar adjustment to the values
returned by gst_element_query_position.

This is not a problem but my question is, how should I obtain the
segment rate? I imagine there must be some way of querying the pipeline
for the rate once it is in paused state, but how?

Thanks in advance,
Andy Robinson, Seventh String Software, www.seventhstring.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Sa, 2016-04-23 at 14:55 +0100, Andy Robinson wrote:
> I imagine there must be some way of querying the
> pipeline for the rate once it is in paused state, but how?

You could try the SEGMENT query, if something in your pipeline is
answering it then it will contain the rate.

But the bigger question is why you need to query the rate and don't
know it already. In the end it was your code that was setting that
exact rate via a seek :)


Also what's the bigger picture here? Why do you want to convert from
stream time to the scaled stream time by rate (which is not exactly the
running time in general, but maybe you actually want the running
time?)?

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Andy Robinson]

On 25/04/16 07:21, Sebastian Dröge wrote:

> On Sa, 2016-04-23 at 14:55 +0100, Andy Robinson wrote:
>> I imagine there must be some way of querying the
>> pipeline for the rate once it is in paused state, but how?
>
> You could try the SEGMENT query, if something in your pipeline is
> answering it then it will contain the rate.
>
> But the bigger question is why you need to query the rate and don't
> know it already. In the end it was your code that was setting that
> exact rate via a seek :)
>
>
> Also what's the bigger picture here? Why do you want to convert from
> stream time to the scaled stream time by rate (which is not exactly the
> running time in general, but maybe you actually want the running
> time?)?
>

Even if I don't do any seek, a Segment event goes down the pipeline and
it has a rate of 0.5 - I know this from putting diagnostics in the pipeline.

The file is here if you are interested:
http://www.seventhstring.com/other2/JAttendraiShort50.mov
It plays ok in Parole Media Player on Linux, or QuickTime on Mac. It's
60 secs long and was produced, using QuickTime, by slowing down a 30 sec
clip to half speed.

When I play it in my app, I find that when I want to seek using
gst_element_seek_simple within this video I must use the pre-slowdown
times, e.g. if I want to seek to the 40th second of the 60 second video,
I must actually seek to a time of 20 secs, and also must make a similar
adjustment to the values returned by gst_element_query_position.

It seems to me that I need to get that 0.5 rate number and use it as a
multiplier when I call gst_element_seek_simple but if there is a better
way, please advise me.

Of course, maybe the file is simply erroneous, illegal, though it does
play ok in some (not all) players.

Regards,
Andy Robinson, Seventh String Software, www.seventhstring.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Mo, 2016-04-25 at 09:20 +0100, Andy Robinson wrote:

> On 25/04/16 07:21, Sebastian Dröge wrote:
> >
> > On Sa, 2016-04-23 at 14:55 +0100, Andy Robinson wrote:
> > >
> > > I imagine there must be some way of querying the
> > > pipeline for the rate once it is in paused state, but how?
> > You could try the SEGMENT query, if something in your pipeline is
> > answering it then it will contain the rate.
> >
> > But the bigger question is why you need to query the rate and don't
> > know it already. In the end it was your code that was setting that
> > exact rate via a seek :)
> >
> >
> > Also what's the bigger picture here? Why do you want to convert from
> > stream time to the scaled stream time by rate (which is not exactly the
> > running time in general, but maybe you actually want the running
> > time?)?
> >
> Even if I don't do any seek, a Segment event goes down the pipeline and 
> it has a rate of 0.5 - I know this from putting diagnostics in the pipeline.
>
> The file is here if you are interested:
> http://www.seventhstring.com/other2/JAttendraiShort50.mov
> It plays ok in Parole Media Player on Linux, or QuickTime on Mac. It's 
> 60 secs long and was produced, using QuickTime, by slowing down a 30 sec 
> clip to half speed.
>
> When I play it in my app, I find that when I want to seek using 
> gst_element_seek_simple within this video I must use the pre-slowdown 
> times, e.g. if I want to seek to the 40th second of the 60 second video, 
> I must actually seek to a time of 20 secs, and also must make a similar 
> adjustment to the values returned by gst_element_query_position.
>
> It seems to me that I need to get that 0.5 rate number and use it as a 
> multiplier when I call gst_element_seek_simple but if there is a better 
> way, please advise me.
>
> Of course, maybe the file is simply erroneous, illegal, though it does 
> play ok in some (not all) players.

You could add a pad probe for downstream events on the sinkpad of the
sink, and there catch the SEGMENT event to know the rate. Or
alternative the SEGMENT query as mentioned in the previous mail. If
it's not implemented in elements you're using, it should be implemented
there.

In the sample file you sent seem to be multiple edit list segments, the
second one being supposed to be played back with a rate of 0.5. From a
playback application point of view this shouldn't matter though, which
might mean that qtdemux is missing to also adjust the stream time
accordingly if the position query returns unexpected values for you.
Can you file a bug about that?

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Andy Robinson]

On 26/04/16 07:30, Sebastian Dröge wrote:
> In the sample file you sent seem to be multiple edit list segments, the
> second one being supposed to be played back with a rate of 0.5. From a
> playback application point of view this shouldn't matter though, which
> might mean that qtdemux is missing to also adjust the stream time
> accordingly if the position query returns unexpected values for you.
> Can you file a bug about that?

It's done, https://bugzilla.gnome.org/show_bug.cgi?id=765669

Regards,
Andy Robinson, Seventh String Software, www.seventhstring.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel