|
From: Roman S. <rv...@Su...> - 2004-01-31 03:08:37
|
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 |