Announcement

Collapse
No announcement yet.

AMD/ATI: where is the FLOSS video decoding?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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?


  • #2
    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.

    Comment


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

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

      Comment


      • #4
        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.

        Comment


        • #5
          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; 05 September 2008, 07:24 PM.

          Comment


          • #6
            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.

            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.

            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.
            Test signature

            Comment


            • #7
              Hi, thanks for responding!
              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?

              Comment


              • #8
                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.

                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; 05 September 2008, 08:59 PM.
                Test signature

                Comment


                • #9
                  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).

                  Comment


                  • #10
                    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; 05 September 2008, 09:24 PM.
                    Test signature

                    Comment

                    Working...
                    X