[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
function
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
difference
is pretty small. Without this trade-off option there was no way I could
achieve
real-time encoding of 1080i50 video on two Opteron cores (the performance
target
of my work for the BBC).
> What does the #define _exactly_ change? We have many variables in
AVCodecContext
> but its hard to suggest a specific one without knowing precissely what
that
> #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
trial
quantizations at various steps in order to do this. These trial
quantizations
are one of the most time-consuming parts of the encoder. With the #define
set
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
need
fewer trial quantizations to find an acceptable step size (although the
resulting
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.
Regards,
Dan
More information about the ffmpeg-devel
mailing list