GNOME Bugzilla – Bug 653649
[ffmpegdec] complains in basic encoding / decoding pipeline
Last modified: 2012-09-10 07:39:39 UTC
Running e.g. following pipeline leads to repeated ffmpeg complaints w.r.t. 'header damaged': gst-launch-0.10 videotestsrc ! ffenc_mpeg4 ! ffdec_mpeg4 ! xvimagesink This may simply be "blame ffmpeg/libav", but AFAIK this is a bit of a regression as we usually managed to avoid such extent of (e.g.) complaints
WORKSFORME! My gst-ffmpeg is 4a66ecdf2577c3f9e7cffb143f3907edea01e00f. Which is presumably what you meant by "regression".
It was indeed introduced by the bump to latest libav 0.7 BUT only when multi-threading is enabled in the decoder. If you specify max-threads=1 on the decoder, it doesn't spurt out any errors.
Haven't figured out how to provide a *simple* reproducible failure example to the libav folks. Anything here fails with more than one thread : http://samples.mplayerhq.hu/V-codecs/MPEG4/ Whoever feals like banging their head at ffplay and trying to figure out how to make it 100% certain that it uses 1) more than one thread with the -threads option and 2) uses the software mpeg4 decoder is welcome to do so.
> BUT only when multi-threading is enabled in the decoder. If you specify > max-threads=1 on the decoder, it doesn't spurt out any errors. I think for the release we should default to max-threads=1 to play it safe (this was only added a week ago, I think it needs more testing). We can use an environment variable to default to a different setting for advanced guinea^Husers.
Ok, looks like no one is picking up the ball on this one, so I'll set the default thread numbers to 1 for this release.
Sounds like we have to. For the record, multithreading for h.263/mpeg4 is even more recent than enabling multithreading: It was only introduced during the bump of libav to 0.7.
commit 2f638309240356ce7a2a3759c962da46f9209f83 Author: Edward Hervey <edward.hervey@collabora.co.uk> Date: Mon Jul 11 10:47:26 2011 +0200 ffmpegdec: Set default number of threads to 1 Too many suspicious errors/warnings pop up when more than 1 thread is used. Fixes #653649
Looks like this is back again, and came along with re-enabling MT support: commit 99e61c5f3b8cec62091bb76cb074aa883f92a74c Author: Edward Hervey <edward.hervey@collabora.co.uk> Date: Mon Oct 17 16:27:36 2011 +0200 gstffmpegdec: Re-enable MT-decoding by default Now it's at least h264 decoding affected: videotestsrc num-buffers=100 ! x264enc! ffdec_h264 ! xvimagesink has lots of complaints as the following (no problem though with max-threads=0): ---- 0:00:00.864087210 5274 0x3673800 ERROR ffmpeg :0:: AVC: nal size 1874020843 0:00:00.864125693 5274 0x3673800 ERROR ffmpeg :0:: AVC: nal size 1874020843 0:00:01.079201833 5274 0x3673800 ERROR ffmpeg :0:: AVC: nal size -1067711296 0:00:01.079288506 5274 0x3673800 ERROR ffmpeg :0:: AVC: nal size -1067711296 0:00:01.169615359 5274 0x25dd720 ERROR ffmpeg :0:: AVC: nal size 510164604 0:00:01.169687016 5274 0x25dd720 ERROR ffmpeg :0:: AVC: nal size 510164604 0:00:01.435166703 5274 0x3673800 ERROR ffmpeg :0:: AVC: nal size -749465889 0:00:01.435200157 5274 0x3673800 ERROR ffmpeg :0:: AVC: nal size -749465889 ----
Also see https://bugzilla.gnome.org/show_bug.cgi?id=668012 I remember seeing this once myself, though it works at the moment, with an up to date gst-ffmpeg. Suggests something fishy going on.
*** Bug 665564 has been marked as a duplicate of this bug. ***
Seems to work for me in 1.0 (tested with h264 and mpeg4)
This was caused by sending empty buffer to ffmpeg before decoding. This confused the decoder thread state when frame based multi threading is enabled. The decoder should only be flushed on EOS. IIRC it is fixed now.