[GSoC] GPU hardware assisted H.264 decoding via OpenGL GLSL shaders - developers only

Actually I was referring to the question mark at the end (unsure if you've started?), not the *maybe*. I jest. I'm sure that was an accident and you're not just trying to keep us on the edge of our seats.

What do you think will be the minimum OpenGL ARB (GLSL) version in the hardware requirement? OpenGL 1.4 + GLSL, 1.5 + GLSL, or 2.0?
http://en.wikipedia.org/wiki/GLSL
http://en.wikipedia.org/wiki/OpenGL_ARB

Rudd Wrote:I've decided to do it in OpenGL/GLSL simply to be the most compatible.

Will you be using an existing framework like VAAPI and/or Gallium, or?

Rudd Wrote:

• *maybe* shaders used in the xbox GPU

But the XDK and Xbox nativly only support DirextX/Direct3D/HLSL, right?, ...though I understand that GLSL shaders can be converted to HLSL shaders (and vice versa) and there are free software tools out there that help you do that convertion.

PS! Have you had time to follow the code progress of these other related GSoC projects?:
http://www.bitblit.org/gsoc/g3dvl/index.shtml
http://code.google.com/soc/2008/dirac/ap...71C6F4785F

Gamester17 Wrote:What do you think will be the minimum OpenGL ARB (GLSL) version in the hardware requirement? OpenGL 1.4 + GLSL, 1.5 + GLSL, or 2.0?
http://en.wikipedia.org/wiki/GLSL
http://en.wikipedia.org/wiki/OpenGL_ARB

I Believe it's going to be a strict OpenGL 2.0 requirement, however, i'm still reworking how I do some things so it might end up as OpenGL 1.5. +GLSL. I'm still not sure all what openGL functionality I will end up using

Gamester17 Wrote:Will you be using an existing framework like VAAPI and/or Gallium, or?

I'm doing it right now directly as a modification to FFMPEG's h264 decoder. I'll try and keep the code not to tied to FFMPEG's constructs so as to perhaps port it to VAAPI or something similar the future, however I felt this would provide the most immediate results. Also VAAPI seems like it would be a bit out of my scope as it would entail learning implementing VAAPI support into FFMPEG, as well as implementing various VAAPI functionality into the gallium drivers to actually get a working gpu assisted decoder.

Gamester17 Wrote:But the XDK and Xbox nativly only support DirextX/Direct3D/HLSL, right?, ...though I understand that GLSL shaders can be converted to HLSL shaders (and vice versa) and there are free software tools out there that help you do that convertion.

PS! Have you had time to follow the code progress of these other related GSoC projects?:

Oh, well, unfortunately the Xbox GPU paper doesn't go as far as actually sharing their HLSL code. It only outlines the algorithm they used for their shaders, so i'd have to implement them myself in GLSL(and there shouldn't be a reason why an algorithm used in HLSL shaders couldn't be used for GLSL shaders). it'd be more items i'd have to test/compare to the FFMPEG's CPU implementation so I am not sure if I will get around to it.

I have been following the gallium project, and the progress he's making has been very good. I believe he's finished the softpipe implementation and is going to be working on adding it to the hardware driver soon. I try to peak into the dirac mailing lists occasionally, but I don't know if there's any other sort of public presence that project has.

Rudd Wrote:I Believe it's going to be a strict OpenGL 2.0 requirement, however, i'm still reworking how I do some things so it might end up as OpenGL 1.5. +GLSL. I'm still not sure all what openGL functionality I will end up using

The reason I as is that the Mac Mini just features an Intel GMA950 graphic controller which only supports OpenGL + GLSL, and the Mac Mini have recently become quite a popular platform for XBMC (both as XBMC for Linux and XBMC for Mac). I fully understand if you originally aim at OpenGL 2.0 as the scope for this project but it would be great later (after and outside of the original scope) detection and software fallback could be added for any GLSL extensions not support by the GPU hardware (thus automaticly run any decoding processes not supported by the GPU on the CPU instead).

Rudd Wrote:I'm doing it right now directly as a modification to FFMPEG's h264 decoder. I'll try and keep the code not to tied to FFMPEG's constructs so as to perhaps port it to VAAPI or something similar the future, however I felt this would provide the most immediate results.

Cool, that is probably the smartest way to go given the time allotted by Google Summer of Code to produce some kind of result that will be usable by the end-user.

I not sure but I think another related GSoC project is the generic frame-level multithreading support effort for FFmpeg, however it will not be usable by yourself as it is now, but when that project is complete and fully integrated into the main FFmpeg SVN (hopefully soon after GSoC period is done this year) then that H264 decoder code could maybe used to more effectivly multi-thread the decoding to move some processes to the GPU that way.
http://code.google.com/soc/2008/ffmpeg/a...705A5D5DBB
http://wiki.multimedia.cx/index.php?titl...ng_support
The 'development-in-progress' files for that project will sooner or later in the FFmpeg Google Summer Of Code repository:
svn://svn.mplayerhq.hu/soc/
http://svn.mplayerhq.hu/soc/

Gamester17 Wrote:The reason I as is that the Mac Mini just features an Intel GMA950 graphic controller which only supports OpenGL + GLSL, and the Mac Mini have recently become quite a popular platform for XBMC (both as XBMC for Linux and XBMC for Mac).

and for Windows on Mac also

Any more progress for us?
I haveto nag every couple of weeks becus it is a intrestring project =)

It is extremely interesting. I will be following very closely

I would be willing to pool funds for continued work after GSOC finished, but lets see where it lands first.

Same here, this new development is very exciting and to my knowledge is unique in the HTPC space, it should allow people to build boxes capable of 1080p without needing high end processors like the e8400, hopeful saving power and noise in the process too.

sandos Wrote:I would be willing to pool funds for continued work after GSOC finished, but lets see where it lands first.

Team-XBMC is always accepting donations (http://xbmc.org/support/donate/). While it cannot be guaranteed that your donation will go toward this specific project because we have other expenses as well (monthly hosting costs for one), I'm sure the project managers would be happy to take your requests into consideration when they decide how excess funds will be spent.

I'm very sorry for not keeping updates. Rest assured I am working very hard on it. I've also promised Gamester that I will do weekly updates(at least) from here on out! I'll even try and post some pictures of the decoder in it's current state.

As for my current status, I've run into some problems. I've done almost all the motion compensation shaders as I've listed before, however I've realized That there is probably no efficient way to handle Intrablocks in B/P slices without implementing full on intra-prediction on the GPU. This, unfortunately, will take me a good amount of time I'll post more on this as I think the problem through.

And in regards to donating to keep the GPU project going, I am flattered but that is completely unnecessary. I will definitely continue work after the period is over(Hopefully in a more maintenance role as opposed to a 'finishing it' role, but time will tell). Please, however, consider donating to XBMC. I am sure they would appreciate it