[FFmpeg-devel] dealing with tables in DV codec

Roman Shaposhnik rvs
Wed Sep 10 21:26:24 CEST 2008


On Wed, 2008-09-10 at 08:22 +0100, M?ns Rullg?rd wrote:
> Diego Biurrun <diego at biurrun.de> writes:
> 
> > 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.  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.
> 
> Who gets to decide which machines are important?  Is K6-3 more
> important than SPARC?

Thanks for saying this. On one hand Michael uses embedded systems
as a constant argument in favor of optimizing for such
platforms, but on the other hand there's a clear x86 tilt
that I see. Don't get me wrong I'm not saying the x86 is
NOT important, all I'm saying is that there are other platforms.
Since, by the nature of my employment, I have an easy access
to them it seems that the performance data they produce should
be at least payed attention to.

Thanks,
Roman.





More information about the ffmpeg-devel mailing list