GNOME Bugzilla – Bug 725104
qtdemux: reverse playback and video stream switching failure
Last modified: 2014-03-03 17:28:50 UTC
When attempting to play in reverse or switch video streams within a mov file the playback will freeze. Attempting to seek after this point will result in seek failures. Attempting to switch backwards and forwards will create a segmentation fault. Tested using the playback-test example in gst-plugins-base-1.2.3. Sample video at https://dl.dropboxusercontent.com/u/2546412/13553200.mov
Reverse playback was failing with upstream git, but I couldn't reproduce any segfault. This patch fixes the reverse playback and stream switching. Can you still reproduce the segfault with that? commit 04bd422432119d20c22529a5edcdfc0a0fce1b6b Author: Thiago Santos <ts.santos@sisa.samsung.com> Date: Thu Feb 27 18:55:04 2014 -0300 jpegdec: mark all parsed frames as sync points all jpeg frames are sync points, so mark them as such so reverse playback can properly work with the video decoder base class https://bugzilla.gnome.org/show_bug.cgi?id=725104
(In reply to comment #1) > Reverse playback was failing with upstream git, but I couldn't reproduce any > segfault. This patch fixes the reverse playback and stream switching. Can you > still reproduce the segfault with that? > > commit 04bd422432119d20c22529a5edcdfc0a0fce1b6b > Author: Thiago Santos <ts.santos@sisa.samsung.com> > Date: Thu Feb 27 18:55:04 2014 -0300 > > jpegdec: mark all parsed frames as sync points > > all jpeg frames are sync points, so mark them as such so > reverse playback can properly work with the video decoder > base class > > https://bugzilla.gnome.org/show_bug.cgi?id=725104 I am just trying to compile the version now but having difficulty with configure.
Any change you could join us at #gstreamer on IRC so we try to help with that?
Ok, logged in as Guest39181
Hi Thiago, I cannot see any difference with the new version. I'm sure the patch was compiled, is there any way I can be sure? Gst-inspect-1.0 jpeg shows the source release date as 2014-02-08. I am testing with the basic-tutorial-13 again, reverse playback freezes pipe with a "Unable to retrieve current position" message.
The release date is generated when you run autogen/configure for the module you build. So you are likely testing with an older version. Did you install the new binary or copied it over? The "Filename" field in gst-inspect-1.0 output can tell where it is getting the binary from.
I copied the binary after making it. The file date is as expected. Plugin Details: Name jpeg Description JPeg plugin library Filename /usr/local/lib/gstreamer-1.0/libgstjpeg.so Version 1.2.3 License LGPL Source module gst-plugins-good Source release date 2014-02-08 Binary package GStreamer Good Plug-ins source release Origin URL Unknown package origin dave@Digits-T61:/usr/local/lib/gstreamer-1.0$ ls -la |grep gstjpeg -rwxr-xr-x 1 root root 1162 Feb 20 19:00 libgstjpegformat.la -rwxr-xr-x 1 root root 188883 Feb 20 19:00 libgstjpegformat.so -rwxr-xr-x 1 root root 1131 Feb 20 19:17 libgstjpeg.la -rwxr-xr-x 1 root root 190607 Feb 28 18:55 libgstjpeg.so -rwxr-xr-x 1 root root 190575 Feb 20 19:17 libgstjpeg.so.123
Ok, can you get a GST_DEBUG=6 log of the example when you reproduce the failure? Please attach it to this bug.
Created attachment 270615 [details] GST_DEBUG=4 when reversing playback Log from the pressing of 'd' in basic-tutorial-13 when playing a 3 video stream mjpeg in a mov wrapper. Playback freezes.
Debug level 6 produced so much output the pipeline failed to play.
Was it outputing to a file? It can cause some slowness, but the pipeline should still play when writing to a file. GST_DEBUG=6 yourapp > gst.log 2>&1 This will put the output to gst.log file. In case this is still failing, try generating only relevant logs: GST_DEBUG=2,qtdemux:6,videodecoder:6,*jpeg*:6,*SCHED*:6 yourapp > gst.log 2>&1 Thanks,
The log is too large even compressed so it is here: https://dl.dropboxusercontent.com/u/2546412/gst.log.tar.gz
I have re-encoded a sample video into both avi and Matroska containers and these both now work with mjpegs. The mov file will still either freeze or seg fault so perhaps the problem is in qtdemux not libgstjpeg?
Can you get a stack trace for this segfault? http://live.gnome.org/GettingTraces Also if there are reliable steps to reproduce the segfault you could describe it here. Atm I wasn't able to reproduce it.
Created attachment 270617 [details] [review] qtdemux: prevent segfault after seeking with negative rate Finally was able to reproduce the crash. This patch is a piece of a fix that was applied to master. Everything already works on current git master and will be released in the upcoming 1.3 and following versions. I'd strongly recommend using git master if you depend on reverse playback as lots of fixes have been done there. Those fixes cannot be backported to 1.2.x series because they aren't safe enough and 1.2.x can only take safe bugfixes to avoid regressions. In any case, this patch should go into 1.2 series and will stop the segfault if other developers agree. Please confirm that this patch works for you and if possible confirm that using master also makes everything work.
I have used the git master and all seems to work perfectly. I will now install this on my deployment machine and check with my application. I have not yet had time to try just the patch. Many thanks.
Comment on attachment 270617 [details] [review] qtdemux: prevent segfault after seeking with negative rate Please commit, but explain a bit better in the commit message what exactly the problem here was (EOS checks broken for reverse playback)
*** Bug 725107 has been marked as a duplicate of this bug. ***
Pushed both fixes to 1.2. I'm marking this as fixed now. commit 19a01df528a743e2d5d41e69ed73957c97cd507b Author: Thiago Santos <ts.santos@sisa.samsung.com> Date: Sat Mar 1 01:14:35 2014 -0300 qtdemux: prevent segfault after seeking with negative rate After a seek, the position and segments info of qtdemux are reset to null or invalid values. For reverse playback, qtdemux will seek to a keyframe and play until the next keyframe, then seek to another previous keyframe. This seeking function requires the position and segments info of qtdemux to be properly initialized. Due to a missing check for segment.rate in the movie demuxing loop it would consider the current segment to have ended without having it initialized, leading qtdemux to attempt to do a previous keyframe seek without proper position and segment info data. This would cause a segfault. This patch fixes it by correctly checking for segment boundaries taking the segment.rate into consideration. https://bugzilla.gnome.org/show_bug.cgi?id=725104 commit 5c2a239f6685f6feef75b9af38e5f80bf761b678 Author: Thiago Santos <ts.santos@sisa.samsung.com> Date: Thu Feb 27 18:55:04 2014 -0300 jpegdec: mark all parsed frames as sync points all jpeg frames are sync points, so mark them as such so reverse playback can properly work with the video decoder base class https://bugzilla.gnome.org/show_bug.cgi?id=725104
Comment on attachment 270617 [details] [review] qtdemux: prevent segfault after seeking with negative rate Updated commit message and pushed