GNOME Bugzilla – Bug 675359
[0.11] Frame-based multi threaded decoding is broken with gst-ffmpegdec
Last modified: 2012-06-19 16:11:12 UTC
Created attachment 213361 [details] Patch This has been broken for quite some time. The problem is empty buffer being sent to the decoder on drain before any other data has been sent. This causes the first decoding thread not being initialized properly and the first actual frame being decoded in second thread. With check to prevent drain when no data has been sent yet the decoding works. The patch also enables frame based decoding by default, if this is not desirable I can disable it. The decoding does introduce latency of 1 frame per thread, but the performance benefits are significant.
Actually, the empty buffer on drain causes problems even with data in. I modified the patch to not attempt to drain the decoder in frame-threading mode at all. The entire draining code looks weird to me, does anyone know any actual libav decoder that needs/supports draining? It does make sense for encoders, but why would a decoder create latency if it doesn't have to?
Created attachment 213387 [details] [review] Patch
Created attachment 213394 [details] [review] Patch After discussing this some more with Ronald Bultje at #libav the problem is that the decoder may only be drained on EOS. It must not be drained at any other point. In gst-ffmpegdec it is currently drained on segment event and discont, which is wrong.
commit a3c7cd4643719f1eec1f885c6634e1f4dbdf8f71 Author: Matej Knopp <matej.knopp@gmail.com> Date: Thu May 3 19:02:09 2012 +0200 gstffmpegdec: only drain on EOS See https://bugzilla.gnome.org/show_bug.cgi?id=675359
*** This bug has been marked as a duplicate of bug 678365 ***