GNOME Bugzilla – Bug 697829
Reverse playback freezes for h264 in AVI container
Last modified: 2018-01-13 11:11:23 UTC
Created attachment 241292 [details] Python testcase (using GObject Introspection) I've attached a test case which seeks in a file, waits a few seconds, then attempts to reverse playback of the file. For mp4 containers (using qtdemux) containing an h264 stream, this test case is fine. For AVI containers, the test case freezes. A sample file is available here: http://www1.datafilehost.com/d/51ada03a I've also reproduced this by remuxing Big Buck Bunny and using it with the attached python script: ffmpeg -i ~/big_buck_bunny_480p_h264.mov -vcodec copy -acodec copy big_buck_bunny_480p_h264_remux.avi
Created attachment 241299 [details] Python testcase (using GObject Introspection)
Created attachment 241300 [details] Corrected example using gi
Still a problem with latest GIT master.
The link provided seems no longer valid, so I performed a remux as indicated. As such, the results may or may not be on the same page/clip/mileage. The remuxed clip is at least partially bogus in that the codec_data for AAC is invalid, so audio playback fails. Since the test script runs a mainloop without checking for messages (error or EOS) it does indeed "hang" (with some displayed video image). If the audio part of the pipeline (in the script) is removed, then it sort of works. That is, there is accelerated reverse playback from about 100s to 0s which then hangs: * 100s to 0s since that is the position at time of reverse seek and no end position is given * accelerated because the segment has no specific stop time, so no calculations required for sync are possible (this is either a corner case bug or as designed in this case for seeking) * hangs in the end because no EOS messages are considered So, depending on clip involved and notion of "freeze", things seem OK. If there is another way to reproduce ...
This seems to generally work fine for me. With your script, I notice that reverse playback is superfast and lots of these are output on the terminal: (python3:5595): GStreamer-CRITICAL **: gst_segment_to_running_time_full: assertion 'stop != -1' failed If I change the stop parameter in the seek request from Gst.SeekType.NONE, position) to Gst.SeekType.SET, position) it all works as expected.
(In reply to Tim-Philipp Müller from comment #5) > This seems to generally work fine for me. > > With your script, I notice that reverse playback is superfast and lots of > these are output on the terminal: > > (python3:5595): GStreamer-CRITICAL **: gst_segment_to_running_time_full: > assertion 'stop != -1' failed > > > If I change the stop parameter in the seek request from > > Gst.SeekType.NONE, position) > > to > > Gst.SeekType.SET, position) > > it all works as expected. Entirely possible, probably a lot has happened in 5 years ;) Feel free to close.