[FFmpeg-devel] dealing with tables in DV codec

[Roman Shaposhnik]

On Wed, 2008-09-10 at 07:41 +0200, Diego Biurrun wrote:
> On Tue, Sep 09, 2008 at 01:51:06PM -0700, Roman Shaposhnik wrote:
> > 
> > as I promised, I tried to come with alternative ways of dealing
> > with macroblock placement in DV codec, and it seems that no
> > matter what I use on Xeon and Opteron it is basically a toss up.
> > There's no speed gain, there's no speed loss. The tables can
> > go so it is a net gain. Now, on SPARC I see a stable speed 
> > loss of about ~3% or so. And I suspect that the same will
> > be true on any chip with a low clock speed.
> > 
> > Now, I'm publishing a temporary diff to solicit public comments
> > on how the calculations can be optimized even further. If nobody
> > comes up with any kind of good ideas -- I don't know what to do.
> > Michale has always told us that even ~3% is significant enough. 
> > So it needs to be dealt with before any change can occur.
> 
> I don't think SPARC is important.

It might not be important as a customer target (although, having
some internal exposure of how Sun customers use FFmpeg and who
at least some of these customers are I would like to disagree)
but it is definitely important as a non-x86 architecture. It would
be fullish for us to turn FFmpeg into FFmpeg-x86, would it not?

>   Let me know what I will have to do
> and I will benchmark on my trusty old K6-III 500.  Then you will have
> numbers for a low clock speed x86 system.

Take SVN, add START_TIMER/STOP_TIMER calls to libavcodec/dv.c 
like they are added in a paptch. Compile everything. Copy
the ffmpeg to ffmpeg_original. Take a patch from the email I've 
sent and apply it to SVN. Recompile everything. Copy
the ffmpeg to ffmpeg_new. Run a couple of trial runs like these:

  $ ./ffmpeg_* -y -i ~/1080i50.mov -an -f rawvideo /dev/null

Note the difference in dezicycles.

Thanks,
Roman.