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 660421 - [queue2] blocked pipeline when using tee and mpeg2enc on size 520x416
[queue2] blocked pipeline when using tee and mpeg2enc on size 520x416
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other All
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-09-29 07:44 UTC by Julien Isorce
Modified: 2011-12-09 02:10 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Julien Isorce 2011-09-29 07:44:38 UTC
* steps to reproduce :

gst-launch-0.10 videotestsrc ! "video/x-raw-yuv, width=520, height=416" ! \
tee name=t ! queue ! mpeg2enc ! fakesink t. ! queue2 ! xvimagesink

 * actual result :

pipeline is blocked in PREROLL step so playing state is not reached.

 * more infos:

With an other (ex: height=520) it's ok. Or when using queue instead of queue2 then it's ok (that's why I think the problem comes from queue2).

I do not if this is a really a deadlock because we can still close the window of xvimagesink to turn off the pipeline.

The last 3 lines printed by using GST_DEBUG=mpeg2enc:5 are:

0:00:00.177778815 20368 0xb5b00ac8 LOG                 mpeg2enc gstmpeg2encpicturereader.cc:122:LoadFrame:<mpeg2enc0> locking tlock from thread 0xb5b00ac8
0:00:00.177804225 20368 0xb5b00ac8 LOG                 mpeg2enc gstmpeg2encpicturereader.cc:122:LoadFrame:<mpeg2enc0> locked tlock from thread 0xb5b00ac8
0:00:00.177823176 20368 0xb5b00ac8 LOG                 mpeg2enc gstmpeg2encpicturereader.cc:131:LoadFrame:<mpeg2enc0> thread 0xb5b00ac8 waiting
Comment 1 Vincent Penquerc'h 2011-09-29 12:32:21 UTC
It looks like the mjpegtools encoder stalls in encoding while gathering buffers, and will only start outputting encoded buffers after it's seen a few input buffers.
It just happens that the queue2 doesn't have quite high enough a byte limit, and will block before mpeg2enc decides it's seen enough to start outputting, which in turns makes the pipeline finish prerolling.

Not sure increasing the default queue2 limit would solve much, as the de facto limit probably depends on the size of the input (though that's a guess - BTW, it doesn't work either when changing height to 520, it starts to work as I decrease resolution, consistent with that hopothesis).
Comment 2 Vincent Penquerc'h 2011-09-30 14:23:14 UTC
Can you please check whether increasing the queue2 limits makes it work for you, so we know this is really the issue you're seeing ? I'm a bit uncertain given your statement that using a height of 520, which is higher, works.
Comment 3 Julien Isorce 2011-09-30 15:34:05 UTC
Hi, I was wrong, height of 520 (width=520) does not work. So you probably right.
Moreover using WxH=520x416, it works when using at least max-size-bytes=4900000 for queue2 (default is 2097152)
Comment 4 David Schleef 2011-12-09 02:10:48 UTC
Closing as notabug.