[GEM-dev] pix_movieDS and updated pix_videoDS

IOhannes m zmoelnig zmoelnig at iem.at
Tue Aug 22 16:48:59 CEST 2006


chris clepper wrote:
> On 8/22/06, IOhannes m zmoelnig <zmoelnig at iem.at> wrote:
>>
>>
>> >
>> > We could replace the VFW handling for pix_film with DS if desired.
>>
>> i am all for it, but are there any chances, to put the code into filmDS
>> and videoDS classes instead of using [pix_movieDS]/[pix_videoDS] ?
> 
> 
> pix_movieDS is just a place holder.  I made a new class to speed up working
> with the consultant and also to try out some tricks for speeding up decode

ah, i understand.

> and texturing.  The pix_film DS code would replace the filmAVI code.  
> Should
> I just overwrite the VFW stuff or make a filmDS class? I just modified the
> existing videoDS as that is what is used for pix_video on Windows.

i think it would be best to make a filmDS class.
just imagine somebody would want to have a recent version of Gem on win98...

> 
>> Right now the DS stuff works OK, but not using the 'suggested' (read
>> > strongly enforced) MS path results in pretty severe performance
>> > penalties.  I may try to hack in YUV handling to help that out.
>>
>> does the yuv-texturing work on w32?
> 
> 
> No, and therein lies the hack.  I'm thinking about adding a method to
> pix_movieDS that would unpack the Y U V into R G B for texture upload and
> then have a pixel shader convert it to real RGB.  I have no idea if this
> would be useful to anyone other than me because it would require a
> [fragment_program] and the correct shader to work.

wouldn't it be better to have this in [pix_texture]?
performing a runtime-check (on systems that have no native GL-support 
for YUV), whether the renderer supports fragment shaders, and if so, 
upload the shader and use that. if it doesn't support shaders, use the 
CPU fallback.
this way, not only [pix_movie] would have the speedup, but also 
pix_video,...

the shader could be hard-coded into the pix_texture-class, so there is 
no dependency on external files.
(shader programs tend to be smaller than i.e. fonts)

mfga.dsr
IOhannes




More information about the GEM-dev mailing list