Page 1 of 2 12 LastLast
Results 1 to 10 of 20

Thread: AMD/ATI: where is the FLOSS video decoding?

  1. #1
    Join Date
    Nov 2007
    Posts
    67

    Default AMD/ATI: where is the FLOSS video decoding?

    So ATI will allow decoding of Blu-ray using a "Catalyst" driver.
    But only available to OEMs. Only for Linux. And I assume that
    "Catalyst" is binary only? (Wikipedia doesn't say)

    Binary-only drivers are 100% USELESS!

    We need FLOSS drivers that decode video. Xv and XvMC at a minimum.
    Longer term add H.264 and friends.

    When are the UVD docs coming out?

    http://xbitlabs.com/news/multimedia/...Computers.html

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

    Default

    Quote Originally Posted by Dieter View Post
    So ATI will allow decoding of Blu-ray using a "Catalyst" driver.
    But only available to OEMs. Only for Linux. And I assume that
    "Catalyst" is binary only? (Wikipedia doesn't say)

    Binary-only drivers are 100% USELESS!

    We need FLOSS drivers that decode video. Xv and XvMC at a minimum.
    Longer term add H.264 and friends.

    When are the UVD docs coming out?

    http://xbitlabs.com/news/multimedia/...Computers.html


    DMCA would not allow FOSS Bluray Decryption. Much like DVD decryption.

  3. #3
    Join Date
    Nov 2007
    Posts
    67

    Default

    > DMCA would not allow FOSS Bluray Decryption. Much like DVD decryption.

    I'm not looking for Bluray decryption. Just decoding of unencrypted
    video.

  4. #4
    Join Date
    Nov 2006
    Location
    /home/$USER
    Posts
    113

    Default

    Quote Originally Posted by Dieter View Post
    > DMCA would not allow FOSS Bluray Decryption. Much like DVD decryption.

    I'm not looking for Bluray decryption. Just decoding of unencrypted
    video.
    The DRM decryption was integrated with the original UVD in the R600 so tightly that AMD/ATi says that they cannot make any of it public, lest people use it to decrypt the video DRM in violation of the DMCA. The UVD2 in RV670 and R700 cards (HD 3000 and HD 4000) has the DRM stuff slightly more isolated from the decoding and AMD/ATi *may* be able to publish enough specs for Xorg devs to use it while not giving away enough to allow for bypassing the DRM.

    It all goes back to the fact that the studios are of the tack that if you provide a mechanism for somebody to do something illegal, that in itself is forbidden as well. That's an idiotic way to think as then we'd have to ban cars that can go over 15 mph (as they could break some speed limit somewhere), knives (as they could stab somebody), and matches (as they could be used for arson.) The MPAA cartel has enough control that if you tee them off with their DRM stance, they will not allow you to have any future decoding capabilities. There are also NDAs and other legal agreements not to knowingly disclose information for people to use to crack the DRM. Naturally, AMD does not want to run afoul of that. So they have to be very careful in what they do and do not give specs for and probably will further separate the DRM from the decoding in newer cards so they can publish the decoding specs without any hassle from the MPAA. That and you can expect to see some of the massive shader power modern cards have put to use in decoding when things like DRI2 comes out. That's the Xorg developers' can of worms right there, not AMD's or any other hardware manufacturer's.

  5. #5
    Join Date
    Jan 2008
    Posts
    139

    Default

    Here's an idea for AMD: just don't put any kind of decrypting technology in your cards. Stay away from the MPAA and their DRM by targeting your cards to viewers of unencrypted video. You won't have to pay them any licensing fees, you won't have to sign any NDAs, you'll have one less component to manufacture, and you'll be able to open the docs up. Seriously, plenty of people just want to view home videos and hi-def content that was purposefully left unencrypted by the authors.

    Oh, and BTW: Intel is opening up their video decode acceleration right now (unencrypted, obviously)! AMD should be able to do the same.
    - Intel's Linux and Windows driver development teams are working together in sharing their video code between the two platforms. Intel video playback on Linux should improve as a result, but first they're waiting on permission to release some of the Intel 965 video code that's more structured on the Windows side than their current Assembly-based implementation.
    Last edited by stan; 09-05-2008 at 07:24 PM.

  6. #6
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,514

    Default

    Quote Originally Posted by stan View Post
    Here's an idea for AMD: just don't put any kind of decrypting technology in your cards. Stay away from the MPAA and their DRM by targeting your cards to viewers of unencrypted video. You won't have to pay them any licensing fees, you won't have to sign any NDAs, you'll have one less component to manufacture, and you'll be able to open the docs up. Seriously, plenty of people just want to view home videos and hi-def content that was purposefully left unencrypted by the authors.
    The problem with that is we would lose perhaps 80% of our market, since OEMs would no longer purchase our products. No BluRay playback = essentially no OEM customers. We would not have the sales to continue funding state-of-the-art GPUs and would have to more or less drop out of the GPU business.

    Quote Originally Posted by stan View Post
    Oh, and BTW: Intel is opening up their video decode acceleration right now (unencrypted, obviously)!
    Intel already has some decode acceleration (XvMC is the API for MPEG2 decode acceleration)-- the quoted article just talks about "some better video acceleration code" from Windows.

    Quote Originally Posted by stan View Post
    AMD should be able to do the same.
    We have already released the info required to accelerate the MC part of decode acceleration, and I expect we should be able to release the IDCT portion as well. There is another level of decode acceleration which nobody has opened up yet (the dedicated H.264/VC1 decode hardware) and that's what all the fuss is about.

  7. #7
    Join Date
    Jan 2008
    Posts
    139

    Default

    Hi, thanks for responding!
    Quote Originally Posted by bridgman View Post
    The problem with that is we would lose perhaps 80% of our market, since OEMs would no longer purchase our products. No BluRay playback = essentially no OEM customers. We would not have the sales to continue funding state-of-the-art GPUs and would have to more or less drop out of the GPU business.
    Perhaps I don't think like an OEM, but why can't OEMs simply tell their customers: our computers work great for unencrypted videos, but they don't do encrypted ones. That will show people why they shouldn't buy DRM-ed junk. (Rhetorical question...)

    And what about graphics cards for mini-notebooks? I mean, there's not even any room for DVD/Blue-Ray drives in those devices, so why would an OEM require DVD/Blue-Ray decryption technology for them?

    Also, according to Wikipedia, UVD was only introduced in r600 and later. Can AMD open up the video decoding capabilities (MPEG, H.264/VC1, etc) for r100-r500?

  8. #8
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,514

    Default

    Quote Originally Posted by stan View Post
    And what about graphics cards for mini-notebooks? I mean, there's not even any room for DVD/Blue-Ray drives in those devices, so why would an OEM require DVD/Blue-Ray decryption technology for them?
    Good point. If we did a specialized product for mini-notes it might be possible to skip the DRM stuff. Not sure what the extra cost would be (it's less work to leave it in than take it out) but worth looking into.

    Quote Originally Posted by stan View Post
    Also, according to Wikipedia, UVD was only introduced in r600 and later. Can AMD open up the video decoding capabilities (MPEG, H.264/VC1, etc) for r100-r500?
    There are two main parts to decode acceleration - IDCT and MC.

    For MC, we have provided the info required on 5xx and earlier already -- MC acceleration is done on the 3D engine with some special rounding modes -- it's just waiting for someone to want XvMC enough to go implement it or for us to have some free time.

    For IDCT, the IDCT hardware is actually there right through to the end of the 6xx family, ie it overlaps with UVD and only goes away with the arrival of UVD2 in the 780 and HD4xxx parts. I am going to look at opening up IDCT hardware after we get 6xx/7xx 3D engine and some basic power management info released (I'm still thinking both of those are higher priority).

    The IDCT hardware was designed for MPEG2 decode but at first glance it looks like it should work for H.264 and VC-1 as well (VC-1 and one of the H.264 levels has a variety of different block sizes). MC should work fine for any of the standards.

    The XvMC API can support MC-only or IDCT+MC decoding today, so there should be enough info out now to write an XvMC driver for R3xx through R5xx.
    Last edited by bridgman; 09-05-2008 at 08:59 PM.

  9. #9
    Join Date
    Jun 2008
    Posts
    26

    Default

    I'd really like h.264 decode. I like the special DRM free part idea if it means someone would write a nice open driver for the h.264 decoder. OTOH, can decode be done using the shaders? We should have the all the specs we need already. Just need to find someone to do the coding. Or, maybe, we're back to the missing memory manager before we can do anything else. Oh well, stick with the plan: release the 3D and Power docs.

    Rant begins here:
    Seems every thread asking for stable, fast, feature filled drivers (open or closed) ends with "need memory manager/xorg infrastructure". Allocate the programming resources to Xorg (if you haven't already).

  10. #10
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,514

    Default

    Quote Originally Posted by leef View Post
    Rant begins here:
    Seems every thread asking for stable, fast, feature filled drivers (open or closed) ends with "need memory manager/xorg infrastructure". Allocate the programming resources to Xorg (if you haven't already).
    Rant no more. Dave Airlie (Red Hat) is working on the memory manager and our devs are picking up some of the work that Dave would otherwise probably have to do himself. The memory manager work is in the "modesetting-gem" branch of DRM :

    http://cgit.freedesktop.org/mesa/drm...odesetting-gem
    Last edited by bridgman; 09-05-2008 at 09:24 PM.

Posting Permissions

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