GNOME Bugzilla – Bug 680386
avdec-* produce extra big buffers if some encoder used after this
Last modified: 2012-08-08 16:03:06 UTC
if i use some flv to source to encode webm i get currupt, broken video. I assume the reason is that some wrong packet is muxed at the beginning of stream. If i use mkvinfo -v i get unusually small first video packet, since it is a key frame it should be bigger. This packet probably deliver wrong init values to decoder. ways to reproduce: create flv file (i use gst 0.10 to create flv file): gst-launch -e videotestsrc num_buffers=100 ! ffenc_flv ! ffmux_flv ! filesink location=test.flv convert it (attention i encode it with gst 1.0): gst-launch-1.0 filesrc location=test.flv ! decodebin ! vp8enc ! webmmux ! filesink location=test.webm
After some more testing looks like the problem is not vp8enc. It is just more sensible to this issue. For some reasasons avdecoders produce bigger buffers if some encoder placed after it. For example: the buffer size of here will be 152064 bytes, which is incorrect: gst-launch-1.0 -v videotestsrc num-buffers=1 ! avenc_flv ! avdec_flv ! 'video/x-raw, format=I420' ! identity silent=0 dump=1 ! vp8enc ! fakesink | less the buffer size here is 115200 (good): gst-launch-1.0 -v videotestsrc num-buffers=1 ! avenc_flv ! avdec_flv ! 'video/x-raw, format=I420' ! identity silent=0 dump=1 ! fakesink | less If you will compare the dumps, you will see that each frameline has extra 16 bytes at the beginning and at the end.
Created attachment 220513 [details] brocken frame This frame was captured with this pipe: gst-launch-1.0 -v videotestsrc num-buffers=1 ! avenc_flv ! avdec_flv ! 'video/x-raw, format=I420' ! vp8enc speed=7 ! vp8dec ! jpegenc ! multifilesink
Created attachment 220515 [details] good frame and this good frame i can get if i add tee with fakesink. See pipe: gst-launch-1.0 -v videotestsrc num-buffers=1 ! avenc_flv ! avdec_flv ! 'video/x-raw, format=I420' ! tee name=t ! vp8enc speed=7 ! vp8dec ! jpegenc ! multifilesink t. ! queue ! fakesink
Most probably related to setting a alignment of 16 bytes in gst_ffmpegviddec_decide_allocation().
(In reply to comment #4) > Most probably related to setting a alignment of 16 bytes in > gst_ffmpegviddec_decide_allocation(). i disable this part of the code and it works now.
Loosely related to bug #680796
This happens because avviddec assumes that downstream supports GstVideoAlignment if it supports GstVideoMeta.
Actually no. It checks that correctly, some code just doesn't handle it correctly although it should :) I have a fix for vp8enc here. xvimagesink does not handle GstVideoAlignment correctly it seems, everything using GstVideoFrame most probably does.
commit 880359f32b78ed5ddcd4f6ef3f73adcaac2b0d43 Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Wed Aug 8 17:06:20 2012 +0200 vp8enc: Update the per-component strides for every frame too This is necessary because of GstVideoAlignment
Actually nothing wrong in xvimagesink and ximagesink. Can't reproduce it anymore