[FFmpeg-devel] dealing with tables in DV codec

[Roman V. Shaposhnik]

On Thu, 2008-09-11 at 12:35 +0200, Michael Niedermayer wrote:
> > Seems like you've confused the threads, then. I fail to see the
> > relevance of this war story to the issue at hand -- should the
> > change that is a toss up on x86 and ~3% performance degradation
> > on SPARC be included or not. 
> 
> It should not be included as such, 3% speed loss is significant.

Well, I guess we have to do something else, then. I can offer one
solution: resurrect the DV_CODEC_TINY_TARGET, get rid of static
tables, allocate them dynamically and not allocate them at all
for DV_CODEC_TINY_TARGET.

> > > That besides reminds me that rumors say the mlib idct is so inaccurate
> > > that its practically useless.
> > > As iam not able to test, i wonder how bad it really is ...
> > 
> > It is actually pretty decent. At least the portions I used to
> > make the DV codec go. Once again -- I'm talking exclusively
> > about SPARC. I have no interest in mlib on x86.
> 
> DV is a intra codec, it never adds 2 idcts on top of each other, all the
> mpeg & h26* codecs add idcts on top of each other, that makes them much
> more sensitive for idct errors.

Quite fair. I agree.

> > > Divx4-bugs/Lorenna_McKennit-Mummers_Dance-Mononoke_Hime-gabucino.avi
> > > on samples.mplayerhq.hu is a good one to test idcts.
> > 
> > Do you mean just comparing PSNRs or a more involved test?
> 
> i meant ffplay -idct 6 file.avi
> and looking at it
> for comarission you can look at 
> -idct 2 (no artifacts)
> -idct 1 (minor atifacts)
> -idct 4 (major artifacts)

Are you saying I am supposed to just look at it and the problems
will be visible? I'm not against it at all, but I'd rather have
a more objective measure if I have to defend mlib ;-)

> > > Though honestly my gut feeling is that anyone knowing VIS and sparc asm
> > 
> > Do you have anyone like that on the horizon?
> 
> Do you know sparc & vis asm ? :)

I do (although my experience comes from looking at it, not
writing it) -- but I'm not a maintainer of libavcodec/sparc/* ;-)

Thanks,
Roman.