May be its just cool to do stuff on the GPU. :cool:
I read about it before on the Phoronix forums. For example; nasty race conditions =x
It's not done yet, and it's using an older version of the ffmpeg source, but they do have the beginnings of a OpenGL+GLSL H.264 implementation. I haven't read the whole thing yet, but on the last page (10 as of yesterday, I think), there's a link to a github.com repository which has compiling code, although I think it currently freezes when playing videos.
Would this be something like what you were describing?
Yep, that looks like the kind of thing I'm talking about. The problem seems to be that most of these decoders are implemented as summer projects and the work takes longer than a summer ;)
The basic ideas seem pretty straightforward :
- bitstream decode, entropy decode and modified IDCT on CPU (the H.264 version of IDCT is cheap to execute)
- intra-prediction on CPU, at least for I-frames
** move data to video memory on GPU ***
- motion comp (aka inter-frame prediction) on GPU
- blend with residuals on GPU
- deblock filter on GPU
- all decoded frames stored on GPU
I don't remember if B and P frames also use intra prediction or just inter prediction (mo comp) - if they do then that's probably going to be the nastiest part of the implementation.
if you have an old opteron you only have SSE2
this is what you so called "chaos386"
in my point of view the linux-amd64 standard is SSE2! thats because the first 64bit cpus are SSE2!
but ok amd wana have the speed of sse3... means 'chaos386'
LOL chaos386 is a member name in this forum... sorry ...
why not? just nvidia sucks?
"If you want to use GLSL acceleration that still can be done on a 8800 GTS."
if i? sure not the only solution for an geforce8800 customer is to sell this card on ebay and get real amd hardware ;-)
why is nvidia not progamming a GLSL solution for 8800 customers ?
i know why... because GLSL isn't working well for that.