[FFmpeg-devel] FFv1 performance

Peter B. pb
Wed Apr 21 17:17:54 CEST 2010

Michael Niedermayer wrote:
> doing full frames means additional latency so iam trying to avoid it,
> but it is an option worth considering if spliting a frame doesnt work
> out as well as i think it should.
> Either way improving the initial states is a good idea because it would
> improve compression
I see.

> are you sure you used rgb and ffmpeg didnt end up using yuv420 ?
> rgb32 is slower here than yuv420 and rgb24 seems unsupported
Since I tried capturing, I had to use Windows - and VirtualDub with
"ffdshow-tryouts" to get FFv1 support.
RGB24 seemed rather strange anyway, since the video preview went "too
smoothly". Something fishy was going on there - and if you say it
doesn't make sense, than I'm even more certain that it might be caused
somewhere outside of libavcodec.

Just don't mind that issue. I'll do some more tests to figure out what

> btw, compression performance of ffv1 can likely be improved by
> finetuneing the
> various tables for the source material, the default ones have been tuned to
> relatively clean 8bpp yuv420 material.
Is there any documentation about the algorithm behind FFv1?
I presume it would require a bit of reading and knowing-how-it-ticks,
before being able to do such a finetuning.

Peter B.

More information about the ffmpeg-devel mailing list