Re: [libdv-dev] libdv vs. ffmpeg's dv decoding

[Roman S. <rv...@Su...>]

On Fri, Jan 30, 2004 at 12:22:10AM +0100, Andraz Tori wrote:
> Na 1075415506, 2004-01-29 ob 23:31, je Roman Shaposhnick napisal(a):
> >   All it does it performs some additional color-space conversions.
> >   Once again, I don't know if for sure but it seems to me that
> >   mplayer's color-space coversion is not only faster it's better
> >   in terms of quality.
> 
> Well... it does it faster than doing it later separately...

  It all depends on how you do it. See comment bellow:
 
> > > > > so about ffmpeg's dv decoding... is it possible to get yuv888 or rgb888
> > > > > directly from it? 
> > > > 
> > > >   No. Neither it is possible to get it from libdv. There always *is* a 
> > > >   coversion. 
> > > 
> > > yes, but inplace conversion is faster than doing it afterwards. 
> > 
> >   No. 
> 
> Why not?  ... logically it should be faster - because of less cache
> misses at least :)
 
  I'm not saying it's always the case, but you shouldn't worry about cache,
  since for such small stuff as MB you bound to hit it (unless you 
  do something counter-productive ;-)) So it just boils down to how
  much stuff can you do while holding everything in registers.
  Turns out (at least on x86) not too much.
  
> >   I never heard of such formats, so they must be aliases for some
> >   well-established names (of course they could be new ones, which
> >   means I can learn something today, but I doubt it ;-)). On the
> >   other hand, nobody has ever complained about lack of color spaces
> >   in ffmpeg(libavcodec). Please explain what do you mean by
> >   YUV888, YUVA888, YUV161616.
> 
> Well... I am working (helping) on video editing and compositing suite
> called Cinelerra. 

  Ah! Cinelerra. I tried it once but got frustrated with its interface
  pretty quickly, if you know what I mean ;-) Has it changed ?

> Cinelerra supports working in 8 different video modes
> internally, all of them are non-planar, and all of them have all the
> components at the same spatial resolution...
> so basically we have:
> RGB888, YUV888 (pretty obvious, three color components, 8 bits per
> component)
> RGBA8888,YUVA8888 (also pretty obvious)
> RGB161616 & YUV161616 ... like RGB888, but uses 16 bits per component)
> RGBA16161616 & YUVA16161616 ... like above, just alpha channel added.
> 
> As you see, it supports above the normal quality video editing... it is
> also meant for high-end and high definition editing... (it supports
> rendernodes, background rendering etc...).

  Interesting. Can you tell where in practice such colorspaces are 
  usefull ? Especially YUVA16161616.

  Well, anyway, the attached patch speeds up the process 3 times. At least
  on my machine. The next step I've tried (but not yet ready to post
  in a form of a patch) actually reduces picture size to 90x60 and
  skips even more computation. Making it 8 times faster than the original.
  
  Let me know if you find its usefull.
  
Thanks,
Roman.

P.S. You're supposed to test it like this:

./ffmpeg -hurry_up 1 -i capt054.dv -an -f rawvideo /dev/null