[FFmpeg-devel] dealing with tables in DV codec

Roman Shaposhnik rvs
Wed Sep 10 21:32:29 CEST 2008


On Wed, 2008-09-10 at 17:35 +0200, Michael Niedermayer wrote:
> On Wed, Sep 10, 2008 at 03:51:27PM +0200, Diego Biurrun wrote:
> > On Tue, Sep 09, 2008 at 01:51:06PM -0700, Roman Shaposhnik wrote:
> > > 
> > > Now, on SPARC I see a stable speed loss of about ~3% or so.
> > 
> > While we're discussing performance: qdv still performs about 50% better
> > than FFmpeg on certain samples, do you know the reason?  An example is
> > 
> > http://samples.mplayerhq.hu/V-codecs/DVSD/henrich-weirdqt.mov
> 
> I cant say anything about this file as ive not looked at it, but dv renders
> macroblocks in a random order that could be rather hard on the cpu caches.
> 
> as ive already sugested to roman but have not heared a awnser for yet is
> to try to replace movq by movntq in put_pixels_clamped_mmx() and check
> that thats also used. It would be interresting to know if that has
> any effect on speed.

It actually had a clearly observable negative impact -- ~20%. Just to 
be clear on what I did the patch is in the attachment. So no, it doesn't
help.

> Also changing the decoder to decode MBs in a less random order would likely
> lead to large speed gains.

Hm. There are two sides to it -- what is being read and what is being
written. I don't think you can have both of them in cache-friendly
ordering. Thus one side always pays cache penalty. I'm not familiar
enough with iDCT implementation to know how much it'll benefit
from the output being in cache friendly order. But it is an intriguing
opportunity to be exploited. I'll try it out today and will report back
to the list.

Thanks,
Roman.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: movq.patch
Type: text/x-patch
Size: 1740 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080910/acbde613/attachment.bin>



More information about the ffmpeg-devel mailing list