chris clepper wrote:
On Apr 28, 2005, at 2:23 AM, IOhannes m zmoelnig wrote:
in theory(!) we should be able to handle this (or most of it) by just fixing some preprocessor defines in the GemPixUtil.h and recompile the whole thing. this of course implies, that people used those defines.
It would be burning to try and do this on the fly for the codecs and input devices that use 'yuvs' instead of '2vuy'.
well, since these are preprocessor prefines you have to know at compile time what you want. probably they are not preprocessor defines but declared as "static const" which just shifts the problem from the preprocessor to the compiler: you have to know what you want at compile time
thinking while i'm writing i notice, that the major problems might be in the altivec code. correct ? (i guess there is no way to use those shift-constants,... in a general but still optimized way within SIMD)
what i mean is (since i keep saying "what i mean", i guess i am starting to have serious problems to express myself...) that the preprocessor defines - like "chU" or "chRed" - might not be used that much in the alitvec-code: i think the byte-ordering is somewhat hardcoded in the altivec (or of course MMX, to not be unfair) instructions as they are used in Gem.
Altivec giveth and also taketh away, but in this case the bad bit of QT code is something that should use Altivec and doesn't. Probably the best way to go is write an Altivec pixel packing swizzler routine from scratch. A 12-15% hit is a lot better than 40%, and although my G4 plays one 720p, this is really something for G5s only where the penalty is likely to be much smaller.
yes, i guess such a swizzler wouldn't be a very good idea. one unfortunate thing is, that currently all the colorspace-conversion routines in GemPixUtil.h imply, that the source and destination buffer are different, and it think that in-place manipulation might be faster. but after more thinking i guess that something like the following might well work in place: m_image.setCsizeByFormat(YUVS); m_image.from2VUY(m_image.data);
(just thinking aloud)
I might make a switch for pix_movie to play both formats since it doesn't pass anything to the other pix_objects. pix_movieHD! I heard it was 'the year of HD' from somewhere, now where did I hear that? ;)
please do not make a [pix_movieHD] !! why not integrate it into the normal [pix_movie] ?
is there a way to detect whether an arbitrary movie is stored in YUVS or in 2YUV before doing the actual decoding ? so that if the slow QuickTime-conversion would be used you can take the short way to the "bad" format and either do the conversion "by hand" or upload it directly to the gfx-card without having to bother the other pix-objects.
mfg.asd.r IOhannes