[FFmpeg-devel] [PATCH] DVCPRO HD - revised two-part patch

Dan Maas dmaas
Sat Jan 5 11:47:06 CET 2008

> "Have you benchmarked it on the existing DV material or only
> on DVCPRO HD? Also, what architectures did you run your tests on?
> I'm a bit surprised when you say it could even be faster, since for the
> original DV the lookup tables seemed to give us some advantage over the
> computation of offsets."

I benchmarked encoding and decoding DV25 on a Core 2 Duo (MacBook Pro).
The fastest runs for both versions were only 0.1% different, with the
version being faster. Granted I only tested a short video clip.

>> I have a compile-time #define for
>> changing a quality-speed tradeoff in the DV100 encoder...
>   Do you actually need this functionality? How much worse the
> performance becomes?

The performance difference is very significant and the image quality
is pretty small. Without this trade-off option there was no way I could
real-time encoding of 1080i50 video on two Opteron cores (the performance
of my work for the BBC).

> What does the #define _exactly_ change? We have many variables in
> but its hard to suggest a specific one without knowing precissely what
> #define does.

For each DCT block, the encoder tries to find the finest quantization
step such that all of the AC data fits within the bit budget. It performs
quantizations at various steps in order to do this. These trial
are one of the most time-consuming parts of the encoder. With the #define
to 0, the encoder considers all possible step sizes. With the #define set
to 1,
the encoder considers only a subset of all possible step sizes, so it will
fewer trial quantizations to find an acceptable step size (although the
step size will less close to optimal).

> Also maybe the algorithm could be changed to be high quality and fast at
the same time? 

If the optimization wizards on this list can do that, I'm sure our users
would be
highly appreciative :). I have taken this code as far as I can on my own.

I'll rewrite the comments into Doxygen format along with any other changes
once you've had
a chance to review the patch.


More information about the ffmpeg-devel mailing list