GNOME Bugzilla – Bug 765669
qtdemux: Incorrect handling of video file which has an internal rate not equal to 1
Last modified: 2016-05-31 14:27:20 UTC
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
Created attachment 327230 [details] [review] qtdemux: properly activate segment with rate != 1.0 This fixes it for pull mode. For push mode it is a bit tricky as no proper qt segment handling is done, except for the initial segment startup. After seeks it will just assume a stream with a default segment. More and non-trivial changes might be needed.
Created attachment 327249 [details] [review] qtdemux: improve edts segment handling after seeks in push mode The same for push mode. gst-validate tests still happy.
commit 00f23053b1f27c6857a2153b39e1344d2d6e9eaf Author: Thiago Santos <thiagoss@osg.samsung.com> Date: Tue May 3 13:59:54 2016 -0300 qtdemux: improve edts segment handling after seeks in push mode Properly handle edts segments for push-based operation seeking. We only support edts that a single segment that has media at the end, being preceeded by any number of gap segments. This also allows the qt segment rate to be respected after seeks https://bugzilla.gnome.org/show_bug.cgi?id=765669 commit 6604614dc53e76b4a16a6e19841efc5989002f79 Author: Thiago Santos <thiagoss@osg.samsung.com> Date: Tue May 3 10:41:06 2016 -0300 qtdemux: properly activate segment with rate != 1.0 Also use the qt rate to identify the position within a qt segment to properly translate playback time to qt media time https://bugzilla.gnome.org/show_bug.cgi?id=765669
Comment on attachment 327249 [details] [review] qtdemux: improve edts segment handling after seeks in push mode Committed with some minor changes (functions signature and some documentation)