beefke Wrote:can you try to patch ffmpeg with the patch proposed by Carl Eugen?

CapnBry Wrote:The problem is not that the patches won't apply to the XBMC tree, not that there will be compile errors that will need to be cleaned up

Quote:Well what's the big fucking deal, images are images and screen is screen right? NO! OpenGL textures used for the OSD are scaled by GL and composited by GL and then merged with the video (which is a texture) by GL and then it is blitted by GL. VDPAU requires that you do your own software texture scaling and blending by hand before shipping it to VDPAU which will blit it to the screen.

Quote:1) VDPAU can render to X11 pixmap, hey it is a drawable why not. nVidia cards have the extension texture_from_pixmap. We could force VDPAU to render to pixmap, copy it to texture, composite in GL, bob's your uncle = accelerated video decoding. Downside: you lose some of the VDPAU features, like supposedly their vsync code is spot on. There's also a small performance hit for rendering to pixmap as opposed to the screen.

Quote:So #1 looks like the best option available. When is will it be done? When you submit a diff.

CapnBry Wrote:The problem is not that the patches won't apply to the XBMC tree, not that there will be compile errors that will need to be cleaned up, but rather that XBMC software renders to texture then composites the texture to screen via opengl. VDPAU creates what's called a presentation target then hardware decodes frames to that which is bound to an X11 drawable. Compositing OSD in VDPAU requires compositing your own images together and then passing the ready-to-be-drawn image to it for overlay.

Well what's the big fucking deal, images are images and screen is screen right? NO! OpenGL textures used for the OSD are scaled by GL and composited by GL and then merged with the video (which is a texture) by GL and then it is blitted by GL. VDPAU requires that you do your own software texture scaling and blending by hand before shipping it to VDPAU which will blit it to the screen.

Essentially all the UI code and video presentation code in XBMC has to be tossed aside and a whole new system would have to be created because XBMC relies on video hardware to do all that currently. There are two options with various issues:

1) VDPAU can render to X11 pixmap, hey it is a drawable why not. nVidia cards have the extension texture_from_pixmap. We could force VDPAU to render to pixmap, copy it to texture, composite in GL, bob's your uncle = accelerated video decoding. Downside: you lose some of the VDPAU features, like supposedly their vsync code is spot on. There's also a small performance hit for rendering to pixmap as opposed to the screen.

2) Software scale and blend all XBMC graphics to make them available for VDPAU compositing. All the features of VDPAU can be included, however this requires MASSIVE amount of image manipulation in XBMC, negating a majority of the benefit of VDPAU.

So #1 looks like the best option available. When is will it be done? When you submit a diff. Why is someone suggesting users write the code? Because the XBMC devs are the users and the users are the devs. Have you seen how much code goes into SVN every day? If you can't contribute by writing code, you can contribute by not continuously asking for status updates. If you want status updates, watch the SVN log. When you see anything related to VDPAU in the commit log, maybe MAYBE that's when an inquiry is in order.

spiff Wrote:i am an INDIVIDUAL and i have EVERY RIGHT to express my PERSONAL opinions. you have absolutely NO right to reduce me to a mere sheep in a flock

BLKMGK Wrote:Now, I'm not sure who maintains the ffmpeg code in XBMC but whoever it is is probably watching the ffmpeg mailing list and is probably WELL aware of these patches. They are probably playing with them quietly waiting for them to mature or they have a philosophical issue with the closed source stuff and refuse - maybe they just haven't had time.

Quote:2) Software scale and blend all XBMC graphics to make them available for VDPAU compositing. All the features of VDPAU can be included, however this requires MASSIVE amount of image manipulation in XBMC, negating a majority of the benefit of VDPAU.

beefke Wrote:I'm no graphical expert, but isn't it possible to pass opengl textures to vdpau?

nipnup Wrote:I'll admit upfront that I do not have much clue about OpenGL, but couldn't the whole OGL stuff simply be handed to Mesa in this case (albeit at a performance hit of course). I seem to remember XBMC even having an option for software rendering already?

If not, how about simply not having an OSD for the time being to get 1080p decoding on an affordable setup? To me, that's a lot more useful than the OSD...

CapnBry Wrote:No you can't. VDPAU only takes prescaled RGBA data for compositing. The main reason it doesn't take GL textures (my conjecture) is because the VDPAU presentation surface doesn't have any model/view/projection matrix making it impossible to ascertain where in the source OSD image to take a pixel to put on the screen at a given screen X,Y. The method they went for is to make the mapping 1 input OSD image pixel = 1 output screen image pixel.

But that is good news that VDPAU has gotten accepted into ffmpeg, not that it solves any of XBMC's problem with it though.

beefke Wrote:So if I understand you correctly, you would have to put the GL texture on the right position on an opague image (i.e. 1920x1080) and pass that one to vpdau?