GNOME Bugzilla – Bug 722169
Dead lock when transcoding a file to H264/AAC
Last modified: 2014-12-22 16:21:37 UTC
- GStreamer master (all components) - Grab http://agot.be/~lachambre/bug/20101223-1_bb_pl.wmv - Try transcoding it using: gst-launch-1.0 filesrc location=20101223-1_bb_pl.wmv ! decodebin name=demux ! queue ! videoconvert ! videoparse ! x264enc ! mp4mux name=mux ! filesink location=gst.mp4 demux. ! queue ! audioconvert ! audioresample ! audioparse ! faac ! mux. - After a while the pipeline is stuck in a dead lock; see the log http://agot.be/~lachambre/bug/gst-transcode-deadlock.log.gz Looks like there is something wrong with the wmv file. I tried transcoding it using ffmpeg directly and it didn't manage to transcode the full file. But at least gst shouldn't get stuck and stop as well.
Does it also deadlock with x264enc tune=zerolatency ? If yes, your audio queues need to be bigger.
(In reply to comment #1) > Does it also deadlock with x264enc tune=zerolatency ? If yes, your audio queues > need to be bigger. Yes it does, see http://agot.be/~lachambre/bug/gst-transcode-deadlock-zero-latency.log.gz How can I increase the size of those queues?
On the audio queue right after the demuxer add the properties: max-size-time=<value in ns> max-size-buffers=<value> max-size-bytes=<value> and you can set to 0 for infinite. I can confirm that increasing only the audio queues makes it work.
Is any action needed here?
There is obviously something wront with the source file being transcoded but at the very least gst should stop with an error instead of locking.
(In reply to comment #5) > There is obviously something wront with the source file being transcoded but at > the very least gst should stop with an error instead of locking. I have the impression that there is no deadlock, but a pipeline stall due to queues being too short. Would it be possible to clarify ?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!
So with this command the pipeline is no longer stuck indeed: gst-launch-1.0 filesrc location=20101223-1_bb_pl.wmv ! decodebin name=demux ! queue ! videoconvert ! videoparse ! x264enc ! mp4mux name=mux ! filesink location=gst.mp4 demux. ! queue max-size-bytes=0 max-size-time=0 max-size-buffers=0 ! audioconvert ! audioresample ! audioparse ! faac ! mux. Is it expected to have gst-launch keeps running forever if the pipeline is stuck because of a queue being full? It's not very friendly to user who has no idea what's going on without looking at logs. Also, the generated file is huge (2.3G) comparing to the original one (362M) and Audio is wrong. See http://agot.be/~lachambre/bug/gst.mp4 Is this because the source file is bugged or is there a bug somewhere?