[FFmpeg-devel] dealing with tables in DV codec

Michael Niedermayer michaelni
Thu Sep 11 12:35:45 CEST 2008


On Wed, Sep 10, 2008 at 07:27:13PM -0700, Roman V. Shaposhnik wrote:
> On Wed, 2008-09-10 at 23:06 +0200, Michael Niedermayer wrote:
> > On Wed, Sep 10, 2008 at 12:46:22PM -0700, Roman Shaposhnik wrote:
> > > On Wed, 2008-09-10 at 21:37 +0200, Michael Niedermayer wrote:
> > > > > 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. 
> > > > 
> > > > /me cleans romans glasses.
> > > > 
> > > > I suggest you ask balatoni denes about how easy it was to get a half optimal
> > > > sparc vis idct into ffmpeg.
> > > 
> > > I'm actually unaware of what you are referring to. Please educate me.
> > 
> > balatoni denes tried to get a half optimized idct in and i nicely told
> > him that it has to include all tricks and optimizations we could think of.
> > We ended up with something that was clearly quite a bit faster than
> > what he submitted first, that is between all the complaints about how
> > little time he had and how evil we were for not just acceptiing it as
> > is.
> 
> 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.


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


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


> 
> > > So one of the things I'm trying to do is to see whether the code
> > > that is really needed for FFmpeg (medialib is huge, we only need
> > > like 2% of it) could be OSed under a reasonable license that would
> > > allow direct inclusion into FFmpeg sources.
> > > 
> > > Should I stop it?
> > 
> > stupid question, 
> 
> repeat after me: there are no stupid questions, there are no stupid
> questions ;-)
> 
> > 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 ? :)


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

If you really think that XML is the answer, then you definitly missunderstood
the question -- Attila Kinali
-------------- 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/20080911/a40f5d98/attachment.pgp>



More information about the ffmpeg-devel mailing list