After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 742172 - omxmjpegdec doesn't stop processing after receiving EOS
omxmjpegdec doesn't stop processing after receiving EOS
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-omx
1.2.0
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-01-01 10:50 UTC by chwongie-gst
Modified: 2018-11-03 13:00 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description chwongie-gst 2015-01-01 10:50:13 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
Comment 1 Sebastian Dröge (slomo) 2015-01-01 11:00:52 UTC
Can you get a backtrace of all threads when it hangs after EOS?
Comment 2 Sebastian Dröge (slomo) 2015-01-01 11:01:08 UTC
Also a debug log with GST_DEBUG=omx*:6 would be useful :)
Comment 3 chwongie-gst 2015-01-01 18:23:34 UTC
(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/
Comment 4 Sebastian Dröge (slomo) 2015-01-01 23:05:32 UTC
(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.
Comment 5 chwongie-gst 2015-01-02 02:25:16 UTC
(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 :'(
Comment 6 Sebastian Dröge (slomo) 2015-01-08 12:45:16 UTC
You need -g in CFLAGS, not CPPFLAGS.
Comment 7 chwongie-gst 2015-01-08 14:06:14 UTC
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! :(
Comment 8 Gilson 2015-07-19 17:58:53 UTC
I can also reproduce this when recording from an IP Camera. Should I provide evidence or configuration info?
Comment 9 Nicolas Dufresne (ndufresne) 2015-07-22 15:06:34 UTC
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
Comment 10 Gilson 2015-07-22 22:53:36 UTC
(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
Comment 11 Gilson 2015-07-22 23:38:25 UTC
(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
Comment 12 Thiago Sousa Santos 2015-07-23 15:27:54 UTC
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.
Comment 13 Gilson 2015-07-27 11:58:32 UTC
Hi Thiago, should I add any other info?
Thanks
Comment 14 Vivia Nikolaidou 2018-05-06 11:08:49 UTC
Information provided seems to be adequate. Setting back to NEW.
Comment 15 GStreamer system administrator 2018-11-03 13:00:21 UTC
-- 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.