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 504642 - mpeg2enc deadlock
mpeg2enc deadlock
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
0.10.14
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-12-20 10:46 UTC by Austin Lund
Modified: 2008-06-12 13:36 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Austin Lund 2007-12-20 10:46:05 UTC
The following command produces a deadlock in the mpeg2enc plugin.  

gst-launch filesrc location="file.mov" ! qtdemux name="demux"  avimux name="mux" ! filesink location="output.avi" { demux. ! queue ! ffdec_mpeg4 ! videorate ! mpeg2enc ! queue ! mux. }  { demux. ! queue ! decodebin ! audioconvert ! audioresample ! ffenc_mp2 ! queue ! mux. } 

The file I'm using (i.e file.mov) is actually http://oodt.jpl.nasa.gov/better-web-app.mov.  It is over 300mb.

With debug on level 4:

0:00:03.190904000 18949 0x89cdb0 DEBUG             mpeg2enc :0:: REST GOP INIT
0:00:03.191621000 18949 0x89cdb0 DEBUG             mpeg2enc :0:: Frame I T=11017 A=062485  Xi=1460741.30 Xp=620347.82 Xb=0.00
0:00:03.206175000 18949 0x89cdb0 DEBUG             mpeg2enc :0:: Frame I A= 13456 4639808.21: I =  10163 P =  4253 B =   inf
0:00:03.212212000 18949 0x89cdb0 INFO              mpeg2enc :0:: Frame    48    48 I q=43.10 sum act=3473.21119    
0:00:16.464923000 18949 0x606080 DEBUG              GST_BUS gstbus.c:335:gst_bus_post:<bus2> [msg 0x864910] posting on bus, type application, GstLaunchInterrupt, message=(string)"Pipeline\ interrupted"

Note the timestamp.  gdb shows all threads waiting at a poll()
Comment 1 Tim-Philipp Müller 2007-12-20 11:54:51 UTC
> The following command produces a deadlock in the mpeg2enc plugin.  
>  ...
> gdb shows all threads waiting at a poll()

This is often not a deadlock, but usually means either that your pipeline is incorrect (probably some incompatible caps somewhere, and gst-launch is waiting for more pads to appear that don't appear), or that one of your queues isn't big enough.

Try:

 gst-launch-0.10 filesrc location=better-web-app.mov  ! decodebin2 name=d  avimux name=m ! fakesink    d. ! queue max-size-bytes=0 max-size-buffers=0 max-size-time=0 ! videorate ! mpeg2enc ! m.  d. ! queue max-size-bytes=0 max-size-buffers=0 max-size-time=0 ! audioconvert ! audioresample ! ffenc_mp2 !  m. -v

Comment 2 Austin Lund 2007-12-20 20:59:47 UTC
Ok.  That seems to work in a way.  Instead of waiting one of the plugins, the CPU spends most of it's time in IOwait and heaps of memory is used and eventually my system becomes completely unresponsive.  

But at least it does seem to work.
Comment 3 Austin Lund 2007-12-20 21:18:54 UTC
But removing max-size-bytes=0 from both seems to do a world of good.
Comment 4 Austin Lund 2007-12-20 21:21:10 UTC
(In reply to comment #3)
> But removing max-size-bytes=0 from both seems to do a world of good.
> 

For a little while.... but then it still stops.
Comment 5 Austin Lund 2007-12-21 00:23:56 UTC
Another point... there seems to be no audio in the output when the fakesink is replaced with a filesink.  Perhaps the audio queue is empty and the video one grows and grows causing the problems I just described.
Comment 6 Mark Nauwelaerts 2008-03-04 17:59:04 UTC
The situation described above is predictably outlined in
http://gentrans.sourceforge.net/docs/head/manual/html/howto.html#sect-mpeg-encoding

To elaborate here; (at present) mpeg2enc does not put timestamps on its output buffers.  avimux tries to do the best it can with this, and assumes that these buffers provide some sort of codec/extra-data and makes sure these go in first.
Unfortunately, in this case, it never stops.  So avimux keeps on "pulling in video" from the input file.  This creates a huge video/audio imbalance (that can carry on as long/large the queues can handle it) which will eventually block the pipeline.  As such, actually, the video content grows and grows, regularly emptying the video queues in between, whereas the audio queues will grow and grow and never be emptied.  And indeed, whatever output may have been made should only contain video.

mpeg2enc can not really be blamed either (well, you might :) ), having no "official" libmpeg2enc specs telling it what to do with provided output (AFAIK?)  So, that only leaves some hope and the work-around given in URL above, or using mpeg2enc updated with the patches in bug 520329, which does make some effort at providing output timestamps.  Tests then show it does generally work out well  (though don't know about the particular input file).