GNOME Bugzilla – Bug 742172
omxmjpegdec doesn't stop processing after receiving EOS
Last modified: 2018-11-03 13:00:21 UTC
To reproduce: 1. gst-launch-1.0 -e filesrc location=<any mjpeg encoded video file> ! <fileformat>emux ! omxmjpegdec ! fakesink 2a. either wait for the video conversion to be "completed" 2b. or press Ctrl+C to interrupt the process 3. gst-launch-1.0 stucks at "Waiting for EOS..." Note: I reproduced this bug with three mjpeg encoded files, with different formats and resolutions. The command `gst-launch-1.0 -e filesrc location=<any mjpeg encoded video file> ! <demuxer> ! omxmjpegdec ! fakesink` gives the following output: Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock ^Chandling interrupt. Interrupt: Stopping pipeline ... EOS on shutdown enabled -- Forcing EOS on the pipeline Waiting for EOS... Then it hangs until I interrupt it again Partial log of the same command with --gst-debug=4: <SNIP> handling interrupt. Interrupt: Stopping pipeline ... EOS on shutdown enabled -- Forcing EOS on the pipeline Waiting for EOS... 0:00:06.398498069 13399 0x1b11350 INFO GST_SCHEDULING gstpad.c:4275:gst_pad_get_range_unchecked:<filesrc0:src> getrange failed, flow: eos 0:00:06.398854065 13399 0x1b11350 INFO GST_SCHEDULING gstpad.c:4478:gst_pad_pull_range:<qtdemux0:sink> pullrange failed, flow: eos 0:00:06.615163362 13399 0x1d0be00 INFO h264parse gsth264parse.c:1326:gst_h264_parse_update_src_caps:<h264parse0> setting framerate in caps 0:00:06.615507358 13399 0x1d0be00 INFO baseparse gstbaseparse.c:3623:gst_base_parse_set_latency:<h264parse0> min/max latency 0:00:00.066666666, 0:00:00.066666666 handling interrupt. Interrupt: Stopping pipeline ... Interrupt while waiting for EOS - stopping pipeline... Execution ended after 0:00:14.645657038 Setting pipeline to PAUSED ... <SNIP> Remarks: * It also breaks decodebin because decodebin may use omxmjpegdec to decode mjpeg videos Workaround: * use jpegdec instead of omxmjpegdec Other users that are probably affected by this issue: http://www.raspberrypi.org/forums/viewtopic.php?t=52797 https://stackoverflow.com/questions/18234107/gstreamer-hangs-while-generating-timelapse-from-jpegs-on-raspberry-pi
Can you get a backtrace of all threads when it hangs after EOS?
Also a debug log with GST_DEBUG=omx*:6 would be useful :)
(In reply to comment #1) > Can you get a backtrace of all threads when it hangs after EOS? Uploaded: http://paste.ubuntu.com/9655534/ Unfortunately, the backtrace doesn't look helpful. (In reply to comment #2) > Also a debug log with GST_DEBUG=omx*:6 would be useful :) Uploaded: http://paste.ubuntu.com/9655464/
(In reply to comment #3) > (In reply to comment #1) > > Can you get a backtrace of all threads when it hangs after EOS? > > Uploaded: http://paste.ubuntu.com/9655534/ > Unfortunately, the backtrace doesn't look helpful. Yes, get a backtrace of all threads. That's possible with > thread apply all backtrace in gdb.
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #1) > > > Can you get a backtrace of all threads when it hangs after EOS? > > > > Uploaded: http://paste.ubuntu.com/9655534/ > > Unfortunately, the backtrace doesn't look helpful. > > Yes, get a backtrace of all threads. That's possible with > > > thread apply all backtrace > > in gdb. http://paste.ubuntu.com/9657383/ Interesting. I built gst-omx with the CPPFLAGS -g . The debug symbol seems not to be available in the backtrace :'(
You need -g in CFLAGS, not CPPFLAGS.
Still get nothing useful. Here is the new paste: http://paste.ubuntu.com/9692862/ Here is the command I used to compile gst-omx: LDFLAGS='-L/opt/vc/lib' CPPFLAGS='-I/opt/vc/include -I/opt/vc/include/IL -I/opt/vc/include/interface/vcos/pthreads -I/opt/vc/include/interface/vmcs_host/linux' CFLAGS='-g' ./autogen.sh --with-omx-target=rpi --prefix=/usr/local && make install I used the env. var. GST_PLUGIN_PATH=/usr/local/lib/gstreamer-1.0/ when launching gst-launch-1.0 so that omxmjpegdec loads. I probably did something wrong again! :(
I can also reproduce this when recording from an IP Camera. Should I provide evidence or configuration info?
Sebastien asked for a backtrace with debug symbol, if you could provide one, that would be useful. A patch that fixes it could also be nice ;-P
(In reply to Nicolas Dufresne (stormer) from comment #9) > Sebastien asked for a backtrace with debug symbol, if you could provide one, > that would be useful. A patch that fixes it could also be nice ;-P Hi Nicolas, The backtrace is on http://paste.ubuntu.com/11922938/ Thanks
(In reply to Gilson from comment #10) > (In reply to Nicolas Dufresne (stormer) from comment #9) > > Sebastien asked for a backtrace with debug symbol, if you could provide one, > > that would be useful. A patch that fixes it could also be nice ;-P > > Hi Nicolas, > > The backtrace is on http://paste.ubuntu.com/11922938/ > > Thanks Just notice there are missing symbol tables, let me know if the backtrace is good enough. Also generated a huge debug log with GST_DEBUG=omx*:6 at http://paste.ubuntu.com/11923018/ Thanks
It seems like the EOS buffer never arrives at the output port. After the last buffer the _loop() just keeps waiting on the egl_render port for the next buffer that never arrives. Reproduced everytime here.
Hi Thiago, should I add any other info? Thanks
Information provided seems to be adequate. Setting back to NEW.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-omx/issues/5.