Page 33 of 34 FirstFirst ... 2331323334 LastLast
Results 321 to 330 of 340

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

  1. #321
    Join Date
    Jun 2007
    Posts
    406

    Default

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

  2. #322
    Join Date
    Jan 2008
    Posts
    16

    Default 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).

  3. #323
    Join Date
    Jan 2008
    Posts
    16

    Default 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).

  4. #324
    Join Date
    Aug 2007
    Posts
    6,675

    Default

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

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

  5. #325
    Join Date
    Jun 2007
    Posts
    406

    Default

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

  6. #326
    Join Date
    Jan 2008
    Posts
    16

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

  7. #327
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,574

    Default

    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 at 01:49 PM.

  8. #328
    Join Date
    Jun 2007
    Posts
    406

    Default

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

  9. #329
    Join Date
    Jun 2007
    Posts
    406

    Default

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

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

    Default

    Don't worry, I'm not asking the question
    Last edited by bridgman; 01-12-2008 at 02:08 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
  •