Announcement

Collapse
No announcement yet.

AMD Catalyst 7.12 Linux Driver -- The Baby's In Surgery

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

  • Originally posted by yoshi314 View Post
    not only that.

    do you know why most linux distributions do not ship with proprietary drivers, and don't include mp3/mpeg4/h264 support by default, even though there are opensource implementations of those?

    because of software patents in the us. that's why i doubt gfx card vendors will be able to provide h264/xvid/mpeg4 support in their cards in opensource form.

    software patents are even worse than drm, because they don't get that much in our way, so there are only a few people opposing them.
    well, i don't remember one single court to have said: yes there was a patent infringement, since the patents DON'T exist. as stated by the fsf the patents are something that were released but they shouldn't have been. in europe, thanks to god, this is not happening, at least until now. and the reason is: in the us they permit the people to patent whatever they want being it an invention or a block of code, while in europe first they look at what people proposes and then, if the thing really should be approved will proceed with the normal patenting process.

    Thank you for the clarifications! But you have nothing understood about the problem I'm mentioning.

    Yes! You're right XVid would even be better than divx because it's open source. But this is not the question here. It's not a question about open source or not.

    Yes x.264 exists and h.264 can be played by a High End PC on Linux.


    I did never say anything else.


    But the ATI graphical card is there to play h.264 on NORMAL (not high end) PC (with UVD). And that you can't do on Linux!!!
    Because the DRM rights management blocks the opening of the driver.

    So for the moment you CAN'T play h.264 on Linux.
    Yes in the future you can ON SOFTWARE (thats what your libavcodec is for). The x.264 doesn't change anything. It's handled by SOFTWARE.

    For a normal PC it's strictly IMPOSSIBLE to play h.264 and the DRM policy is the reason why!
    hmmm, i think that also xvid or divx aren't hw accelerated on linux. we don't really have a direct hw acceleration on linux. maybe we'll have some after the unified acceleration system. considering the movements of the videocards enterprises towards linux this might happen in a not too long time. at least that's what we hope. anyway, as i've already said, i'd like to see the hw producers to slightly modify their architecture so that to provide average linux customers with hw accelerated videodecoding. until then the only other option is its inclusion inside the proprietary driver.

    Comment


    • Not US patents but DRM

      All I've said is right!

      DRM is the reason why I can't use my graphical card and NOT US-patents!!!

      I've got a radeon hd2600xt.
      This card INCLUDES all US-patents to use it. I've paid all rights to use those patents together with the card.

      It's NOT true that the patents are the reason why I can't use the graphical card. The US-Patents are the same for windows and linux.

      The ONLY reason is that DRM boycotts open source. (They say hypocritically that they don't want to show their encrypting to open source. An attentive forum reader has seen correctly that good encoding consists in the key and not in the procedure.)

      With my graphical card there is NO problem with ffmpeg. Because my card does all critical procedures on hardware and I'm owner of all rights to use it.

      The only problem is DRM.
      (Perhaps also Microsoft).
      They make (illegal) pressure on AMD not to open UVD. The winner is Microsoft because in their (closed) operating system there is no problem with UVD.
      (DRM is also a looser because their h.264 products can't be used by linux users without Penryn).

      Comment


      • divx and xvid not hw decoded

        Yes divx and xvid aren't hardware decoded on linux.
        But the algorithms of h.264 need much more power.
        A normal PC is able to do the decoding of divx and xvid.

        But h.264 fullHD with high bitrates can't even been done by an E6600 (without oc).

        Comment


        • Basically that CPU would be fast enough, there are possibilities to use a faster (win) codec:

          Comment


          • Originally posted by eigerhar View Post
            Yes divx and xvid aren't hardware decoded on linux.
            But the algorithms of h.264 need much more power.
            A normal PC is able to do the decoding of divx and xvid.

            But h.264 fullHD with high bitrates can't even been done by an E6600 (without oc).
            well, for hd-dvds or blue-ray ones you'll really need a home player detached from the pc. i personally haven't yet seen a blu-ray playing on a blu-ray pc, you could do it with a sony high end laptop or pc. when these pcs would really work in outputing 1920x1080 fullhd videos onscreen then we could start to see how much processor do they use and if the hw decoding works. then we could see if it works or not for other oses different than windoze. also, it's not clear if the bd disc would still use mpeg2 (the bd capacity is quite high and could allow it to be used) so that the decoder would be a less stressing one.
            regarding the algorithms of h264 you're in part right: when starting the h264 is quite slow, but after it has started is quite smooth and the algorithms aren't so much of a stressing factor.
            and could you please try to decode a normal h264 of the same resolution and bitrate as the one used in divx or xvid?! the stress is about the same. pardon, the stress is less with the resolution increase since the disk controller would need much more bandwidth with old formats. i'm quite sure that if you'd try to see a film in hd format in h264 it would be about a 3gbs or disk space and will run a normal medium machice, a core2duo with nvidia driver and a 8800 (hopefully also on a hd2400 with 512 or on a hd2600 with 256 ddr2), while a movie in xvid format at 1920x1080, the same as the h264, would be of about 5-6gb and the processor and dma would be stressed more than with h264. why is there no xvid/divx with resolutions superior to 800x600?! cause it's too stressing to decode them on normal medium machines. if you want to do the test search for a full-hd h264 download it and convert into xvid 2 pass and test it. after some days of work on converting it, you won't be able to watch it normally, even on windows.

            Comment


            • Conversion anyway

              I don't think that you're right when you think that xvid/divx is as stressing as h.264.
              Your calculation with the amount of memory doesn't convince. In the calculations h.264-codecs have to expand the picture information to the same size of memory as divx/xdiv (Bitmap-format). Only that h.264 has to do it more often (because of the greater number of steps).
              In the memory (RAM) the size of the picture is independent of the compression (Bitmap-format). The CPU is stressed by the number of steps not by the amount of picture memory. (This memory is IMHO in both cases the same).

              What I've seen of xvid/divx was very impressiv.

              But even the case that xvid/divx is also very stressing, a conversion will do it.
              If I have to convert any way I can also adapt the bitrates to the specs of my CPU.

              (The conversion will be done by some Linux users. The others can copy the divx/xdiv).

              If DRM blocks hw/decoders like UVD, a conversion is needed any way. Any adaption to the user needs (also bitstream) can be done and DRM will lose many buyers of h.264 content.

              Comment


              • There's no question that DRM is a problem when it comes to supporting HW H.264 decode with open source *drivers* (and it seems to be a problem for all the major graphics vendors, not just AMD), but when it comes to supporting HW H.264 decode on Linux (with a closed source driver) that's just a matter of effort and market share.

                This is one of the major reasons why we feel that both open and closed source drivers will be required unless DRM magically vanishes from the world at some point in the future. DRM on audio may be starting to show signs of exhaustion but DRM on video is still alive and growing.

                The main issue in this thread, I believe, is that since the primary market "pull" for H.264 decode has been playback of protected HD content on Windows, all of the initial implementations focused on integrated DRM/decode solutions. This is fine for Windows users, since a solution capable of playing back protected content can also play unprotected content.

                Providing a similar "protected content" solution on Linux is non-trivial because the OS does not have any of the DRM support infrastructure which has been built into Windows for years now, so that infrastructure needs to be re-invented from scratch... and nobody wants to wait for it.

                The question here is "is it possible to do a non-protected HW decode solution that runs on an open source kernel without putting the DRM parts of solutions on other OSes at unacceptable risk ?". The answer is "we think so, but it probably won't be an open source driver". Can you live with that ?

                The next question is "why can't I have it TODAY ??"
                Last edited by bridgman; 12 January 2008, 01:49 PM.
                Test signature

                Comment


                • Originally posted by eigerhar View Post
                  I don't think that you're right when you think that xvid/divx is as stressing as h.264.
                  Your calculation with the amount of memory doesn't convince. In the calculations h.264-codecs have to expand the picture information to the same size of memory as divx/xdiv (Bitmap-format). Only that h.264 has to do it more often (because of the greater number of steps).
                  In the memory (RAM) the size of the picture is independent of the compression (Bitmap-format). The CPU is stressed by the number of steps not by the amount of picture memory. (This memory is IMHO in both cases the same).

                  What I've seen of xvid/divx was very impressiv.

                  But even the case that xvid/divx is also very stressing, a conversion will do it.
                  If I have to convert any way I can also adapt the bitrates to the specs of my CPU.

                  (The conversion will be done by some Linux users. The others can copy the divx/xdiv).

                  If DRM blocks hw/decoders like UVD, a conversion is needed any way. Any adaption to the user needs (also bitstream) can be done and DRM will lose many buyers of h.264 content.
                  huh?!?! i've currently worked with h264 rate adaptation last year and i can tell you that the main difference in h264 when compared to old h263 mpeg3 is the way the frames are handled and the increased temporal and spatial dependency between frames. the way it's done is indeed much more processor consuming that the way xvid/divx does, but i'm not talking about memory just in the ram terms, but primary in the means of bus use. h264 from this point of view is less stressing, because it has to transfer lesser packets that are to be deciphered by the gpu/cpu based on you using hw/sw decoding. xvid/divx is much more stable and its known very well, so that the sw decoders were quite tuned, while h264 wasn't.
                  on the bitmap stuff, you're quite wrong, since xvid contains more full frames while h264 just contains less full frames and a number of secondary frames which contain just the variations from the previous frames. so what is in your opinion more stressing:
                  - a full bitmap reload or
                  - a partial refresh of the old frame?!
                  when you see the tearing and the watermaks on videos this is because the temporal/spatial connection between the frames wasn't decoded properly and the partial refresh wasn't done in the right way.

                  the problem with drm, of my knowledge till today, is not the one that you're telling, but the fact that you'll have to use sw decoding instead of hw one. drm just verifies your system and your support and decides if you're allowed to view it and the way you're allowed to. this means that drm doesn't actually converts the format, which is never done, but only functions as a validation instrument. then the content is decoded by the sw program and based on the driver support it is decoded sw or hw by the system. with non drm content this validation tool lacks and you go directly to the step of decoding.
                  now, the problem we're now talking about is the following: udv which is the video decoding hardware in the boards contains this instrument that validates the content. now, the problem with drm is the following:
                  as drm is a validator knowing how it works could make people write code that could bypass the validator. how this is possible you could ask, and for this reason i'll do a simple example.
                  now, let's say that we have a hw validator that validates a string in input. if the string has appended the right hashcode then the string was written by the signer. we now say that we know how the validation process works, and we can generate hascodes that are validated as genuine we can do the following stuff:
                  get the string we previously had and create another external hashcode for it. now, the box would validate the hascode and surprise: the signer of the string was validated in the right way and the reader of the string will now read that it has been sent by the right signer.
                  this could also be done with drm by intercepting the content before it is read and have it incapsulated into a valid drm code. this would result into copied content to be validated as genuine content and could let you view it the way you like. this is the real thing that the drm group fears. by releasing the specs of how the content validation works they could let users bypass their imposed rights. so in this case it's obvious that companies would never release how drm works.
                  if you would object that drm is an cryptographic stuff, i must tell you that if it were like that then the content would have needed to be deciphered thus increasing exponentially the processor load, which is not the case of drm.

                  as for the conversion part i didn't actually understood what you're trying to tell.

                  Comment


                  • Originally posted by bridgman View Post
                    The question here is "is it possible to do a non-protected HW decode solution that runs on an open source kernel without putting the DRM parts of solutions on other OSes at unacceptable risk ?". The answer is "we think so, but it probably won't be an open source driver". Can you live with that ?

                    The next question is "why can't I have it TODAY ??"
                    i think that we could live with that if it were to be there.

                    if it's you that are making the last question it makes me have some bad feelings about it...

                    Comment


                    • Don't worry, I'm not asking the question
                      Last edited by bridgman; 12 January 2008, 02:08 PM.
                      Test signature

                      Comment

                      Working...
                      X