>
> 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 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.
> 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.
>
> Also, I seem to have destroyed the CVS web browser for our project.
luckily it seems to work for me.
Yeah, it took a while for it to come around.
cgc