Announcement

Collapse
No announcement yet.

A few questions about video decode acceleration

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

  • A few questions about video decode acceleration

    I have a few questions about video decode acceleration:

    1.) I understand that the Avivo video processor's specs can be released without legal issues, but UVD's specs cannot because of output protection stuff. Does this mean that R600+ chips will not be able to have any open-source video decode support, or that their support will be limited to the avivo functions? In either case, I'd like to bring up the suggestion again of a blob for video decoding that the open-source driver could tie into.

    2.) Bridgman, have the people at amd begun to rummage for video decode spec documents? Do they exist? When do you expect you'll have time to start cleaning them up for release?

    3.) This question is more toward the driver developers. What api do you think will be useful for video decode. Is VAAPI the future? Or will extensions to Xvmc work?

  • #2
    1. I understand that the Avivo video processor's specs can be released without legal issues, but UVD's specs cannot because of output protection stuff
    Yep, although the "avivo video processor" is not so much a single processor as a combination of high quality video paths (AVIVO := Advanced Video In / Video Out), some changes to the shader core to process video more efficiently, and some proprietary back-end video processing running on the shaders. If you think about the video pipeline as being decode followed by render, AVIVO is basically very good render acceleration and back-end processing.

    R128 through R6xx all have hardware support for the IDCT and MC decoding tasks; IDCT in dedicated hardware, MC using special modes on the shaders. I'm pretty sure we will be able to open IDCT/MC on all those products, not sure about UVD on 6xx.

    The 6xx family adds UVD, and we run H.264 and VC1 decode on UVD instead of on the existing IDCT/MC hardware. I suspect the IDCT and MC hardware (which we plan to open up) will also be useful for H.264 and VC-1, just not as efficient as UVD. I don't think we have actually tried using IDCT/MC on H.264/VC-1, however.

    Everyone with me so far ? OK, good.

    The 780 IGP is the first of the 7xx family with UVD2, and on those parts the IDCT block gets absorbed into UVD so MPEG2 acceleration is done on UVD as well as H.264 and VC-1.I think our chances of opening UVD on 7xx are actually a bit better than UVD on 6xx, but not sure and haven't spent any time on it yet. My current thinking is to open up IDCT/MC on 1xx-6xx, and try to open UVD on 7xx.

    Bottom line is that I expect we will be able to enable some pretty good decode *and* render acceleration. It may not use every bit of HW in the chip but other than people playing DVDs on long airplane trips while running Linux I doubt anyone will notice the difference.

    2. have the people at amd begun to rummage for video decode spec documents? Do they exist? When do you expect you'll have time to start cleaning them up for release?
    Yes and no. Our focus is 6xx 3d, but we are keeping our eyes open for low-hanging fruit. Dave Airlie reminded me yesterday that we used to have a proprietary API for video acceleration which was pretty small and simple, and that if we could dig up source for that it would be a pretty good ddk for using the IDCT/MC hardware on most of the Radeon parts.

    The specs defintely exist, that's not a problem; the issue is making sure that we can safely and legally release enough info to write a useful driver. Best guess right now is that we'll start spending more time on video in July.

    3. What api do you think will be useful for video decode. Is VAAPI the future? Or will extensions to Xvmc work
    I expect XvMC extensions to be the primary API for a while. VAAPI may be newer and cleaner (although I haven't looked at it enough to be sure) but everyone tends to implement XvMC first then XvMC extensions are just an extension away
    Last edited by bridgman; 06-05-2008, 04:36 PM.

    Comment


    • #3
      Thanks for the answers, Bridgman, that clears a few things up. I get the impression, than, that *any* modern ati card I purchase will get me some kind of video decode acceleration once this stuff is done. It's great news to hear that it might be possible to open up UVD on r700, that would be awesome for making a mythtv box.

      So video accel docs will be worked on once the 3d stuff is all out the door, and you guys are keeping an eye out for things that might be helpful at this point.

      The reason I was asking about VAAPI is that what I've heard is that extending XvMC would be difficult and messy to use, and that it might only expose limited functionality (maybe it would be OK for the idct/mc stuff, but probably not for anything beyond that). Since we're starting from scratch here, it seems to make more sense to me to start on a new architecture that's designed to do what you're trying to. I don't know that much about the intricacies of driver development, but there were concerns that VAAPI is Intel-centric and might not adapt well to other cards. Have any of the devs look at the VAAPI spec? Are these concerns justified?

      Comment


      • #4
        I can't imagine why there would be any legal problems with releasing the docs on any of the video stuff, as long as the details of enabling Macrovision and HDCP are redacted.

        Comment


        • #5
          Macrovision and HDCP are no problem -- they're actually implemented in the output blocks and we released docs on those back in September/October last year.

          This is more serious stuff -- and before you ask, if I could tell you more I WOULD HAVE ALREADY RELEASED THE DOCUMENTS

          Comment


          • #6
            It's stuff so secret that you can't even tell us in general terms what it is and why it's secret? I'm impressed! Sounds like real cloak-and-dagger stuff! :-)

            Anyhow, thanks again for all the hard work you and the team have put into getting the docs released and supporting open driver development! It's nice being able to recommend ATI products to friends, coworkers, etc., with no reservations.

            Comment


            • #7
              He could tell us. But then he'd have to kill us. And that's a little hard over the internet.

              Comment


              • #8
                or perhaps he could have AMD do the right thing, and not stop THEIR users from using THEIR hardware fully, because they need to "protect" the stupidity of some hollywood exec's, trying to maintain the illusion that their DRM works, and havent already been broken.

                reality is, that the DRM is already broken, its null and void, USELESS, it protects NOTHING, everyone that wants to make copies, can do so.

                AMD basically says: "oh, because hollywood wishes to THINK the drm protects their stuff, YOU can not use the hardware you bought", which is just wrong.

                Comment


                • #9
                  It's probably more correct to say "AMD basically says oh, because we and everyone else in the industry signed agreements committing to provide a secure environment for DVD/HD/BD player applications we will honor those agreements".

                  I expect that we will allow you to use all the hardware fully; we just arent sure we can expose it to open source developers without violating pre-existing agreements.

                  If you are saying that we should violate the agreements we have signed, and that we should refuse to deliver the features which 99% of our OEM customers insist we provide, that is not a decision I can make but honestly if I were asked it's not a decision I would recommend. I understand that you're looking for one hardware vendor to take a billion-dollar risk and go against the industry direction on DRM, but so far nobody has identified a way that could work out well for AMD or any other vendor who tried it.

                  I know the popular view is that we would be deluged with customers since they would now be able to play any protected content without restrictions but it doesn't work that way. The DRM hardware just allows us to provide a secure environment for a player app, and the app makes the decision whether to play. No DRM hardware, no secure environment, no play.

                  This discussion really is premature anyways, since I don't know yet how things are going to work out with UVD. I don't have an answer today, so I'm saying "we have no plan to open UVD" (which is the literal truth), but if it turns out that we are able to open UVD does that solve the problem for you ?
                  Last edited by bridgman; 06-06-2008, 04:46 AM.

                  Comment


                  • #10
                    Originally posted by bridgman View Post
                    I know the popular view is that we would be deluged with customers since they would now be able to play any protected content without restrictions but it doesn't work that way. The DRM hardware just allows us to provide a secure environment for a player app, and the app makes the decision whether to play. No DRM hardware, no secure environment, no play.
                    That's BS and you guys at AMD know it just as well as the rest of us. The fact of the matter is that hacks are already being worked out. HDCP, and AACS are already being cracked. Sooner rather then later we will all be able to watch any content protected or not, using nothing but open source players and drivers, and we'll be able to do it 100% transparently.

                    Whether you like it or not this --is-- what is going to happen. If you took this opportunity to help the open source community to achieve this goal, you could single handedly kill DRM entirely in one fell swoop. ATi is the --only-- company who has the market position to dictate to the movie industry what it will and will not do.

                    I really dont care what anybody else says. ATi --can-- kill DRM completely. It's the only company who can, and until they decide to do so we will be stuck with it. And the thing that they are simply too ignorant, or maybe arrogant, to realize is that it wouldnt effect there bottom line at all in any measurable form. Lets face it, open source drivers will exist, so the people who would have used ATi's hardware will still do so, and HDCP, and AACS will be hacked so the people who will be buying and watching DRM'd content will still be able to do so.

                    There is absolutely no valid point at all to continue supporting DRM. All your doing is --wasting-- resources in a --futile-- effort. You should take those same resources and devote them to the open source drivers and help us to develop a better product. Instead of allowing Intel to shape the future of the Linux graphics subsystem you should take the efforts that you have devoted to DRM and your closed driver and reallocate them to the open source community.
                    Last edited by duby229; 06-06-2008, 02:59 PM.

                    Comment


                    • #11
                      duby229, I think we may be talking about different things. I'm talking about how the DRM-related hardware in a graphics chip fits into the big picture; you're talking about whether the overall protection scheme can be cracked.

                      What I'm saying is that if you have a licensed player (any of the HD/BD players available today AFAIK) then it will not play unless the OS tells it that the playback path is secure and that the outputs are either protected or sufficiently low resolution that nobody cares. If you have a player that does not observe the licensing rules, all the DRM hardware in the world is not going to make a difference. This is why I don't see why you're unhappy with the presence of DRM hardware in the chips.

                      DRM hardware and driver support is a pre-requisite for selling into the Windows market, which represents maybe 99% of our sales. I would really like to believe that the movie industry would quake in fear because we refused to support DRM, but the term "bug on a windshield" comes to mind.
                      Last edited by bridgman; 06-06-2008, 06:43 PM.

                      Comment


                      • #12
                        I can't help but agree with duby229 that implementing all the DRM BS is a waste of resources and ultimately a futile effort. As I've said before, I can't help but wonder how much less frustration I'd have suffered if it weren't HDCP.

                        I also can't help but agree with Bridgman that Microsoft is ultimately to blame for all of it. OK so Brigman didn't quite put it like that, but I read between the lines.

                        How many billions of dollars (on top of the billions people actually pay that evil company for their products) have been lost industry-wide supporting Microsoft's hair-brained scheme to pwn the HD download market. If only Hollywood was intelligent enough to see that M$ just wants to make more profits on Hollywood's products than Hollywood does.

                        How many more billions will be lost to hopeless efforts? When will people with the power to do something about it realize that there is no point in preventing copying when copying is exactly what must happen if one is to watch or hear digital media?

                        Comment


                        • #13
                          Originally posted by bridgman View Post
                          duby229, I think we may be talking about different things. I'm talking about how the DRM-related hardware in a graphics chip fits into the big picture; you're talking about whether the overall protection scheme can be cracked.

                          What I'm saying is that if you have a licensed player (any of the HD/BD players available today AFAIK) then it will not play unless the OS tells it that the playback path is secure and that the outputs are either protected or sufficiently low resolution that nobody cares. If you have a player that does not observe the licensing rules, all the DRM hardware in the world is not going to make a difference. This is why I don't see why you're unhappy with the presence of DRM hardware in the chips.

                          DRM hardware and driver support is a pre-requisite for selling into the Windows market, which represents maybe 99% of our sales. I would really like to believe that the movie industry would quake in fear because we refused to support DRM, but the term "bug on a windshield" comes to mind.
                          Fine so be it. Keep doing what you do with Windows. Keep developing the hardware.. Do what you need to do, but Linux simply doesnt need it. We dont need or want DRM support in our device drivers. I understand that you think you need to implement DRM in hardware. I personally believe that if ATi told the content industry to F*** off, they would have no choice but to do it, if they wanted to keep selling content. How many players and computers have ATi chips in them right now? The majority would be my guess.

                          Anyhow that is entirely beside the point. ATi chooses to delude themselves when it comes to DRM, and that is all fine and good. I can live with DRM in hardware as long as that hardware can be completely and totally disabled. And with the open source drivers that will be entirely possible. I'll still be able to watch and record any content I come across whether it is protected or not. Same thing with anybody else....

                          Using the excuse that in order to play back protected content you need DRM in both the hardware and drivers is a flat out lie.

                          This is the point.... Linux doesnt need it. Stop wasting resources like Time, and engineering talent, and documentation, and money and other such things on it. Linux does --not-- need a closed driver. It doesnt need and --shouldnt-- share the same code base as windows. It doesnt need and --shouldnt-- implement DRM in any form under any circumstances. All of those resources doing so are completely wasted. And while that effort is being thrown away, Intel is in the process of shaping the future.

                          Comment


                          • #14
                            Originally posted by duby229 View Post
                            Fine so be it. Keep doing what you do with Windows. Keep developing the hardware.. Do what you need to do, but Linux simply doesnt need it. We dont need or want DRM support in our device drivers.
                            Yep, understood.

                            Originally posted by duby229 View Post
                            I understand that you think you need to implement DRM in hardware. I personally believe that if ATi told the content industry to F*** off, they would have no choice but to do it, if they wanted to keep selling content. How many players and computers have ATi chips in them right now? The majority would be my guess.
                            Regrettably, no. Intel has the largest share, then NVidia and ATI/AMD take turns for the rest, and we kinda change places every few years. This year it's our turn. We all have pretty much the same DRM hardware, and we all have pretty much the same problem opening up HD video acceleration hardware.

                            Originally posted by duby229 View Post
                            Anyhow that is entirely beside the point. ATi chooses to delude themselves when it comes to DRM, and that is all fine and good. I can live with DRM in hardware as long as that hardware can be completely and totally disabled. And with the open source drivers that will be entirely possible. I'll still be able to watch and record any content I come across whether it is protected or not. Same thing with anybody else....
                            Yep; you can do that with a closed source driver as well, that's the point I'm trying to make. You can even do it under Vista -- all Vista does is provide a secure environment where a licensed player can "decode with confidence". If you don't use a licensed player that cares about security, nothing gets in your way. Honest.

                            Originally posted by duby229 View Post
                            Using the excuse that in order to play back protected content you need DRM in both the hardware and drivers is a flat out lie.
                            Sure, but I'm not saying that. I'm saying that a licensed player will only enable decoding if the OS says it has a secure environment, and that secure environment needs DRM hardware.

                            Originally posted by duby229 View Post
                            This is the point.... Linux doesnt need it. Stop wasting resources like Time, and engineering talent, and documentation, and money and other such things on it.
                            We're not spending any time on DRM for Linux, except in our efforts to open up as much hardware as possible for open source driver devs.

                            Originally posted by duby229 View Post
                            Linux does --not-- need a closed driver. It doesnt need and --shouldnt-- share the same code base as windows. It doesnt need and --shouldnt-- implement DRM in any form under any circumstances. All of those resources doing so are completely wasted. And while that effort is being thrown away, Intel is in the process of shaping the future.
                            Actually it does. If you want a really high performance 3d driver, for example, the Linux market isn't big enough to fund the development just for Linux so we share code with other OSes.

                            W E A R E N O T S P E N D I N G A N Y M O N E Y O N D R M F O R L I N U X ! !

                            (Unless a market develops for it, in which case of course we will do it, but we ain't doin' it today )

                            Comment


                            • #15
                              "It's probably more correct to say "AMD basically says oh, because we and everyone else in the industry signed agreements committing to provide a secure environment for DVD/HD/BD player applications we will honor those agreements"."
                              well.. if by secure environment, you mean that people will simply strip the DRM off before it hits the graphics card, which is what is happening now.

                              If you have made such an agreement, you will need to keep it, but the issue is the same, AMD made this agreement, despite the fact that it would limit its users, and have ZERO positive affects whatsoever, it CERTAINLY does not protect anything.

                              "I expect that we will allow you to use all the hardware fully; we just arent sure we can expose it to open source developers without violating pre-existing agreements."
                              What this means for me is: I may be able to use this feature at some point 10 years from now, when there only exists copies of the hardware in a museum.

                              "I know the popular view is that we would be deluged with customers since they would now be able to play any protected content without restrictions but it doesn't work that way." Tell me _EXACTLY_ how i am unable to play "protected" contents as it is, make 100 copies, and violate the copyright by making copies to everyone.. THIS i can do, regardless of what AMD does. AMD giving access to hardware which users purchased changes nothing, except the fact that users can now actually use it..

                              "This discussion really is premature anyways, since I don't know yet how things are going to work out with UVD. I don't have an answer today, so I'm saying "we have no plan to open UVD" (which is the literal truth), but if it turns out that we are able to open UVD does that solve the problem for you ?"
                              Personally i dont expect myself to have much need for UVD, though if ffmpeg incorporated support for it, i might. but What i want is to be able to use all the parts of the hardware i purchased(well, except DRM/HDCP, i dont much care for that). If AMD gives out specs allowing free drivers to do this, then YES, this solves the problem for me, and i suspect, _EVERYONE_ else - what however needs to happen, is that this happens within a reasonable timeframe, and not in time for a museum to deploy it.

                              "DRM hardware and driver support is a pre-requisite for selling into the Windows market, which represents maybe 99% of our sales. I would really like to believe that the movie industry would quake in fear because we refused to support DRM, but the term "bug on a windshield" comes to mind."
                              And providing information to US to make a free driver for non-winblows OS's, suddenly makes windows report that amd catalyst is not a "secure environment"?

                              Comment

                              Working...
                              X