[FFmpeg-devel] dealing with tables in DV codec

Michael Niedermayer michaelni
Wed Sep 10 21:42:30 CEST 2008


On Wed, Sep 10, 2008 at 12:32:29PM -0700, Roman Shaposhnik wrote:
> 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.

:(
thanks anyway


> 
> > 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

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080910/18115415/attachment.pgp>



More information about the ffmpeg-devel mailing list