We had a consultant come by last week and help out with the ridiculous Microsoft DirectShow API. The end result was a new DirectShow handling object, pix_movieDS, and updates to pix_videoDS for recording to disk. I actually know a little something about DS now too.
We could replace the VFW handling for pix_film with DS if desired. 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.
Also, I seem to have destroyed the CVS web browser for our project.
cgc
hi
chris clepper wrote:
We had a consultant come by last week and help out with the ridiculous Microsoft DirectShow API. The end result was a new DirectShow handling object, pix_movieDS, and updates to pix_videoDS for recording to disk. I actually know a little something about DS now too.
that is great.
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] ?
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?
Also, I seem to have destroyed the CVS web browser for our project.
luckily it seems to work for me.
mfg.asdr. IOhannes
On 8/22/06, IOhannes m zmoelnig zmoelnig@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 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
chris clepper wrote:
On 8/22/06, IOhannes m zmoelnig zmoelnig@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
On 8/22/06, IOhannes m zmoelnig zmoelnig@iem.at wrote:
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...
Do we really support Win98? I think 2k/XP is not unreasonable as basic requirements now.
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)
That would be fine until someone (namely me) wants to use a more complex shader. ;)
I haven't actually done anything beyond finding that getting a YUV buffer from DS is faster than RGB when you don't use the DirectX hardware overlays. We shouldn't do any automagic until this is proven to be worthwhile. Also, adding code that makes pix_texutre even more complex and unreadable should not be undertaken lightly!
cgc
chris clepper wrote:
On 8/22/06, IOhannes m zmoelnig zmoelnig@iem.at wrote:
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...
Do we really support Win98? I think 2k/XP is not unreasonable as basic requirements now.
darn, again i forgot the ";-)" nevertheless, i don't see any reason to drop support for wfv-decoding just to not have to add another 2 files....
That would be fine until someone (namely me) wants to use a more complex shader. ;)
I haven't actually done anything beyond finding that getting a YUV buffer from DS is faster than RGB when you don't use the DirectX hardware overlays. We shouldn't do any automagic until this is proven to be worthwhile. Also, adding code that makes pix_texutre even more complex and unreadable should not be undertaken lightly!
true. especially the part about making pix_texture even more complex.
mfg.asdr IOhannes
cgc
-
chris clepper -
IOhannes m zmoelnig