[FFmpeg-devel] About Unchanged Frames

Michael Niedermayer michaelni
Sun May 11 13:21:33 CEST 2008

On Sat, May 10, 2008 at 06:14:55PM -0700, Mike Melanson wrote:
> Michael Niedermayer wrote:
> > On Fri, May 09, 2008 at 11:42:01PM -0700, Mike Melanson wrote:
> >> Hi,
> >>
> >> The type of material I am trying to encode with ZMBV has a lot of 
> >> unchanged frames. It seems that the best ZMBV can do with unchanged 
> >> frames is 11-12 bytes. I seem to recall that it's possible to stuff an 
> >> AVI file with an empty frame (i.e., a '00dc' chunk with a 0-length 
> >> payload) that the demuxer will interpret as an empty frame (I have some 
> >> H.264 AVI files that do this). How can an encoder communicate to FFmpeg 
> >> that the AVI muxer should mux a 0-length frame? When I try to return 0 
> >> from the encode_frame() function, FFmpeg construes that as a skipped 
> >> frame and doesn't mux it.
> > 
> > The avi muxer will add 0 frames as needed depending on dts.
> > Anyway try skip_threshold,
> > if it works (with mpeg4) then your code is buggy
> > if it doesnt then mine is :)
> This gave me a little to work with, although they seem unrelated (dts 
> and skip threshold). I see there is an option called -skip_threshold and 
> a few associated options and that mpegvideo_enc.c cares about them. So I 
> can see how the parameters for comparing the current frame with the 
> previous can be tweaked. But I still don't see how an encoder can 
> communicate to the muxer that a frame is unchanged and that it's safe to 
> mux an empty frame.
> As a test, the file ( http://samples.mplayerhq.hu/fli-flc/a.fli ) has a 
> reasonable number of unchanged frames.
> ffmpeg -y -i a.fli a-mpeg4.avi
> ffmpeg -skip_threshold 10 -y -i a.fli a-mpeg4.avi
> ffmpeg -y -i a.fli -skip_threshold 10 a-mpeg4.avi
> I chose threshold 10 at random. I was aiming for something non-zero, 
> even though I have determined that a.fli has a number of frames 
> unchanged from the previous. None of the resulting a.fli files contained 
>   0-length frames. The smallest were either 36 or 40 bytes.

well 10 seems be too small, 40 is the smallest for this file to have skiped


Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I hate to see young programmers poisoned by the kind of thinking
Ulrich Drepper puts forward since it is simply too narrow -- Roman Shaposhnik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080511/27ff6d91/attachment.pgp>

More information about the ffmpeg-devel mailing list