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 Uchikoma View Post
    Closed source DivX, and the open-source Xvid are implementations of the MPEG-4 (part 2) standards.

    With regards to open source codecs...
    x264 is an open source encoder implementation for h.264, and there are decoding libraries out there for h.264 (libavcodec comes to mind which is also open source -> LGPL). These ones encode and decode (respectively) according to the MPEG-4 Part 10 standard (MPEG-4 Part 10 AVC/H.264). I don't believe they are fully complete, but they're already fairly well used. In which case, there's no reason why DivX would be exclusively established as the codec of choice...never mind H.264, they got Xvid up their alley (and I use Xvid over DivX) to compete with.

    ...if you're talking about DivX (or Xvid) reaching h264 spec levels of compression when referring to open source, it's not going to happen. DivX and Xvid would have to implement the specs for Part 10, and not Part 2, which is what they are currently conforming to.

    For ripping content from the discs, it's not how it's encoded that's the problem. It doesn't matter if the stream is MPEG-2 or MPEG-4 Part 10 encoded. What you would be worrying about is how to defeat the protection preventing you from making that copy.
    i'd like to make just one precisation: h264 is an iso/iec standard codec, which means that it's specs are fully documented and that opensource community could use them to implement it. and this is true for all the iso, itu or ieee standards. do you think that the linux 802.1 stack differs in the specs from the 802.1 stack for windows?! it doesn't in the base code. the same goes with the h264 format.
    i personally like the standardization of things since you don't have to bother anymore for misbehaviours for your standard apps as is happening for example with sites that use iexplore only features which on firefox wouldn't run as they should. this is just an example and this should also let you understood why i'm pro for the standardization of an ooxml version, even if it would need some other work to be of a good level: it would finally make office documents fully compatible with oopenoffice or koffice or whatever opensource app that would want to implement its features. from i've understood reading around the web, the problem with ooxml as it's now is that it was born from a damaged mind and the specs are a true labyrinth (immagine a program wich has nested goto in its source code that point out somewhere in the 20 milions of code lines). this old naughty microsoft is now starting a war between gnome who supports this standard (remember novell agreement and novell own the trademark gnome) and kde which seems to deny its implementation. i really hope that this news given the last month is not true, cause that a war between gnome and kde would only mean damage for opensource community.

    ps. if you still haven't read about the last microboy issue then read here : http://www.linuxjournal.com/node/1006008 this seems to have just been corrected but the following news is even more better :
    http://www.linuxjournal.com/node/1005965
    i haven't read other news about this issue and if it has been also corrected, but i have to say that after removing windows from my pc to stick with gentoo these news would only give make me smile at evening when i come back from work and read them.
    don't you agree?!

    Comment


    • Useless clarifications!!!

      Closed source DivX, and the open-source Xvid are codec implementations of the MPEG-4 (part 2) standards otherwise known as MPEG-4 ASP.
      Open source x.264 and open source libavcodec are encoder and (contains) decoder for the MPEG-4 (part 10) standards, otherwise known as MPEG-4 H.264/AVC.
      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!

      Comment


      • DRM has nothing to do with h264. There are lots of those media files out there, some even in matroska containers. Only on blue-ray or hd dvd the files are encrypted which can be h264 too. And only those can be restricted using offial ways to playback that these only can be viewed using hdcp over dvi (or hdmi). As soon as you find a way to decrypt the data no restrictions will apply to you - you can keep your current hardware and dont need to buy new monitor/gfx card to watch it. Of course your pc has still to be fast enough.

        Comment


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

          Comment


          • Well most problematic are encoders and decss for Linux distributions, like you will not find unrestriced ffmpeg (the ones you find can only encode a part of the possible codecs) or lame (due to mp3 patent) or mencoder (mp3 too and others) usually in official repositories. mplayer can ship when you disable/remove support for css - a pure variant has this feature builtin. Of course you can always build from scatch to get fully working versions.

            Comment


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

                    http://code.google.com/p/coreavc-for-linux/

                    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; 01-12-2008, 12:49 PM.

                          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; 01-12-2008, 01:08 PM.

                                Comment

                                Working...
                                X