If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
In the above depiction of Flash Player's workflow, the video card stands in for the green [Video decoder] box. The key point here is that the decoded video frames need to be accessible by the Player which needs to do its thing before the data can be presented to the user. As of this writing, none of these drivers in Linux allow retrieval of the decoded video data. Their counterpart Windows drivers do allow this which is why this feature is supported in Windows.
Nvidia's Steve Warren answers in the Comments:
This post seems to rest on two basic assertions:
1) Flash must have CPU-access to the decoded video surfaces.
2) Flash can't obtain CPU-access to the decoded video surfaces.
I believe that both of these assertions are wrong, at the very least for VDPAU, and probably for other video APIs as Gwenole claims above; he should know.
Taking the points in reverse order:
VDPAU currently has two different ways of obtaining CPU access to the surfaces. One can use APIs such as VdpVideoSurfaceGetBitsYCbCr or VdpOutputSurfaceGetBitsNative to download the data to the CPU, and then act on the data in any way. I don't believe any media players currently do this, because there's very little point. Alternatively, one can use the VDPAU presentation queue to present the data to an X pixmap. One can then use X APIs, or OpenGL's GLX_EXT_texture_from_pixmap to composite this data with application UI elements. At least XBMC uses this method (specifically GLX_EXT_tfp) very successfully today, even on low-end platforms; it is a very well tested path.
Finally, more mechanisms will be made available in the near future.
On to your second point:
I imagine that the only reason Flash requires CPU-access to the frames is to render/blend the UI on the CPU. I don't think this is the correct approach; GPU acceleration should be used for the UI rendering (or at least upload and blending). VDPAU itself has various rendering/blending/scaling operations built in specifically for this purpose. Alternatively, you could get the video into OpenGL and then use OpenGL's rendering/blending/scaling operations, as XBMC does. Do also note that VDPAU's VdpVideoMixer fully performs the YUV->RGB conversions you mentioned on the GPU, and if Flash really needs, it can download the resultant RGB data after that step with almost no effort.
I also take issue with your point that Flash is somehow fundamentally different to other media players. Specifically, MPlayer renders UI/OSD, subtitles, etc. on top of the video using VDPAU features. XBMC renders a potentially complex and pretty UI over the video using OpenGL. I believe both of these applictions, and others, can also perform network streaming at the same time for example. It sounds like they're both doing the exact same thing that Flash needs to.
Please note that I haven't yet read your "flash uses the GPU" post, or at least note recently. I'll go read it now. Still, I doubt that will change my mind that widely available APIs (across platforms and vendors) such as OpenGL are the correct way to accelerate graphics-oriented applications such as Flash.
In summary: If you have any issues understanding or using VDPAU, please feel free to contact NVIDIA. We'd be very happy to help you.
IMHO those discussions are of the sort that made me read the Phoronix Forum until now, NOT useless and endless rants about long known facts/opinions.
And btw. hi all, first post
Just to add more fuel to the fire MPEG-LA released this today.
MPEG LA’s AVC License Will Continue Not to Charge Royalties for
Internet Video that is Free to End Users
(DENVER, CO, US – 2 February 2010) – MPEG LA announced today that its AVC Patent Portfolio License will continue not to charge royalties for Internet Video that is free to end users (known as Internet Broadcast AVC Video) during the next License term from January 1, 2011 to December 31, 2016. Products and services other than Internet Broadcast AVC Video continue to be royalty-bearing, and royalties to apply during the next term will be announced before the end of 2010.
MPEG LA's AVC Patent Portfolio License provides access to essential patent rights for the AVC/H.264 (MPEG-4 Part 10) digital video coding standard. In addition to Internet Broadcast AVC Video, MPEG LA’s AVC Patent Portfolio License provides coverage for devices that decode and encode AVC video, AVC video sold to end users for a fee on a title or subscription basis and free television video services. AVC video is used in set-top boxes, media player and other personal computer software, mobile devices including telephones and mobile television receivers, Blu-ray DiscTM players and recorders, Blu-ray video optical discs, game machines, personal media player devices and still and video cameras.
Yup. Freeware. At least for me is not enough. It's a tremendous benefit to have the freedom to make money if you want to.
lol, honestly I don't have an issue at all if people/corporation/etc say "If you don't charge for our implementation of xyz then we won't charge you." that is their prerogative. It's their IP they should be able to do what ever they want with it.