[FFmpeg-devel] dealing with tables in DV codec

[Roman Shaposhnik]

On Sat, 2008-09-13 at 19:13 +0200, Michael Niedermayer wrote:
> On Fri, Sep 12, 2008 at 07:49:23PM -0700, Roman V. Shaposhnik wrote:
> > 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.
> 
> Iam not sure about this, but i guess its better than what we have now, so ok.
> But it should be CONFIG_SMALL not DV_CODEC_TINY_TARGET

Got it. 

> > I'm not against it at all, but I'd rather have
> > a more objective measure if I have to defend mlib ;-)
> 
> dct-test is objective, but someone alraedy posted some numbers for that
> (and these number where really scary, being far outside the ranges mandates
> by the specs)

Yeah, well, it used to be that you had to do something like this. IIRC:
+++ dsputil_mlib.c     Tue Mar 18 23:55:41 2008
@@ -416,7 +416,10 @@

 static void ff_fdct_mlib(DCTELEM *data)
 {
+    const mlib_s16 c[1] = {8};
+
     mlib_VideoDCT8x8_S16_S16 (data, data);
+    mlib_VectorMulS_S16_Sat(data, (mlib_s16 *)&c, 64); /* scaling data by 8 */
 }

So I'm not sure whether that was taken into account or not. Now that
we have this conversation going on, I'll try to see what the proper
fix there should look like.

> > > > > 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/* ;-)
> 
> fixed

You know it doesn't work like that, right? ;-)

Thanks,
Roman.