GNOME Bugzilla – Bug 504642
mpeg2enc deadlock
Last modified: 2008-06-12 13:36:31 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()
> 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
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.
But removing max-size-bytes=0 from both seems to do a world of good.
(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.
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.
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).