[Bug 765669] New: Incorrect handling of video file which has an internal rate not equal to 1

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=765669

            Bug ID: 765669
           Summary: Incorrect handling of video file which has an internal
                    rate not equal to 1
    Classification: Platform
           Product: GStreamer
           Version: 1.8.1
                OS: All
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: don't know
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: andy at seventhstring.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

I'm not entirely clear what correct behaviour should be but Sebastian asks me
to file this as a bug so here it is. I quote the conversation:

On Mo, 2016-04-25 at 09:20 +0100, Andy Robinson wrote:
> 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

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.