[GEM-dev] GEM HD

[IOhannes m zmoelnig]

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