How to query the GstSegment "rate"?

[Sebastian Dröge]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160426/f525dde8/attachment.sig>