Page 12 of 15 FirstFirst ... 21011121314 ... LastLast
Results 111 to 120 of 147

Thread: Adobe Rants Over Linux Video Acceleration APIs

  1. #111
    Join Date
    Jul 2009
    Location
    England
    Posts
    103

    Default

    Quote Originally Posted by deanjo View Post
    At one time the pen was mightier then the sword but now days we have shredders and liquid paper.
    Hehe I deleted my comment as I thought It was just getting ridiculous to post one line :P disabled edit FTL! It's true though. Nothing is more powerful than an idea.

  2. #112
    Join Date
    Feb 2010
    Posts
    39

    Default

    Arrgh, I'm sick of this [html5] h.264 vs theora battle, all has been said, please move on...
    And was this news not about Adobe Flash accel. on Linux?

    There were some interesting details and answers in Mike Melanson new Blog Post:
    http://blogs.adobe.com/penguin.swf/2..._problems.html

    He says:
    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:

    Mike,

    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

  3. #113
    Join Date
    Jan 2009
    Location
    Columbus, OH, USA
    Posts
    323

    Default

    There's something so immensely satisfying about seeing weak arguments sunk by a gatling-cannon of common sense. I'm not an NVIDIA user, but good show Mr. Warren.

  4. #114
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,584

    Default

    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.

  5. #115
    Join Date
    Jul 2009
    Location
    England
    Posts
    103

    Default

    Quote Originally Posted by deanjo View Post
    Just to add more fuel to the fire MPEG-LA released this today.
    Sounds like an attempt to push it into the HTML 5 spec before charging massive royalties later

  6. #116
    Join Date
    Apr 2009
    Location
    Toronto/North Bay Canada
    Posts
    877

    Default

    in 5 years where will theora be? Im sure that or another codec will be far superior.

  7. #117
    Join Date
    Dec 2008
    Location
    Australia
    Posts
    880

    Default

    Quote Originally Posted by deanjo View Post
    Just to add more fuel to the fire MPEG-LA released this today.
    Do these corporations have no bounds to their strategic sleazebaggyness.

    I'm with Hoodlum on this one.

  8. #118
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,584

    Default

    Quote Originally Posted by Hoodlum View Post
    Sounds like an attempt to push it into the HTML 5 spec before charging massive royalties later
    Na being that it's a renewal it looks more like a case where "As long as your not making money off it, go ahead and use it.".

  9. #119
    Join Date
    Mar 2009
    Location
    Hellas
    Posts
    1,098

    Default

    Quote Originally Posted by deanjo View Post
    Na being that it's a renewal it looks more like a case where "As long as your not making money off it, go ahead and use it.".
    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.

  10. #120
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,584

    Default

    Quote Originally Posted by Apopas View Post
    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.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •