Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 35

Thread: Revenge On Reverse Engineering

  1. #21
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,386

    Default

    We can't use that architecture for "real" HD decoding, since we would be legally obligated to protect the video data that comes out of the decoder and that's kinda hard to do in an open driver, but it might be a possibility for using UVD on non-HD content if we could properly tamper-proof the binary. The obvious downside is that it's a heck of a lot easier to reverse engineer a single module than a 20 MB driver stack, and if we felt that we could safely release the info we would rather just give it to you than make you dance for it
    Last edited by bridgman; 01-03-2008 at 05:50 PM.

  2. #22
    Join Date
    Jun 2007
    Posts
    406

    Default

    Quote Originally Posted by bridgman View Post
    We can't use that architecture for "real" HD decoding, since we would be legally obligated to protect the video data that comes out of the decoder and that's kinda hard to do in an open driver, but it might be a possibility for using UVD on non-HD content if we could properly tamper-proof the binary. The obvious downside is that it's a heck of a lot easier to reverse engineer a single module than a 20 MB driver stack, and if we felt that we could safely release the info we would rather just give it to you than make you dance for it
    i understand very well your point, but i'll ask you this: what use could be there for reverse eng the modules if someone gives you them working well?! why would someone do reverse eng on something that is working well and loose time doing this? i think it's a stupid thing.
    anyway, i agree with you that releasing something that could break your legal obligation with someone else is a stupid thing. well, i hope that amd will come out with some idea to fix this in the future.

  3. #23
    Join Date
    Jul 2007
    Posts
    403

    Default

    I'd be perfectly fine with a blob for video decoding. I understand the issues here. I hope eventually the industry will wise up and realize that DRM doesn't work, but until that happens, I'd really like to have hardware accelerated video decoding, and if it can't be free, then proprietary is fine.

    I don't expect Richard Stallman would agree, but I think it's best for everyone if free and propietary software coexist.

  4. #24

    Default

    Quote Originally Posted by givemesugarr View Post
    here i am again asking for some clarification about revenge:
    is there some documentation on how to use it?
    i've tried looking around the web for some hours but haven't yet found a list of options or something that could help me start it and when i start revenge it says that the option that i want is not recognized.
    i think that if someone doesn't start to write some help on the matter it won't be so useful in the end.
    There isn't very much documentation right now; I really should write some. There
    is a README included with the latest Revenge from Git. I don't remember whether
    it's included in the last release...

    When I add PCI-ID based card detection a lot of the nastiness from interface
    switches (AGP, PCI-E, etc) will disappear, but I haven't done that yet.

    Btw, the email address in the README currently isn't setup, so you should send
    dumps to me directly.

  5. #25
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,582

    Default

    Quote Originally Posted by bridgman View Post
    We can't use that architecture for "real" HD decoding, since we would be legally obligated to protect the video data that comes out of the decoder and that's kinda hard to do in an open driver, but it might be a possibility for using UVD on non-HD content if we could properly tamper-proof the binary. The obvious downside is that it's a heck of a lot easier to reverse engineer a single module than a 20 MB driver stack, and if we felt that we could safely release the info we would rather just give it to you than make you dance for it
    Why can't we have true HD acceleration of non-DRM'd content?

  6. #26
    Join Date
    Jun 2007
    Posts
    406

    Default

    Quote Originally Posted by deanjo View Post
    Why can't we have true HD acceleration of non-DRM'd content?
    because releasing specs for the free hd video acceleration would let reverse engineering reveal how the drm works in a matter of no time and because usually the hd content (until now) was protected by drm, which is on its last moments of life after sony, the last drm sustainer, has declared that would abandon drm for some of its content - the news is on linux journal breaking news (http://www.linuxjournal.com/node/1006011 ) while the article to which it refers is available directly on business week: http://www.businessweek.com/technolo...013_398775.htm .
    so for example if amd would reveal how udv works for the free part
    on monday someone would have commit a patch to the radeon for the
    drm part. at least that's what i've understood from john's explanation on the matter.

  7. #27
    Join Date
    Jan 2008
    Posts
    2

    Default

    Quote Originally Posted by bridgman View Post
    We can't use that architecture for "real" HD decoding, since we would be legally obligated to protect the video data that comes out of the decoder and that's kinda hard to do in an open driver, but it might be a possibility for using UVD on non-HD content if we could properly tamper-proof the binary. The obvious downside is that it's a heck of a lot easier to reverse engineer a single module than a 20 MB driver stack, and if we felt that we could safely release the info we would rather just give it to you than make you dance for it
    Funny thing how DRM in the end only screws the costumer ;-)

  8. #28
    Join Date
    Nov 2007
    Posts
    1,353

    Default

    So hold on, let me get this straight... We are talking about DRM (Digital Restrictions Management) not DRM (Direct Rendering Manager).... Is that correct?

    If so why cant you just bypass the frontend altogether and just let all those stream processors handle HD decoding directly through something like CTM? Or maybe through an abstraction layer like GLSL or something similar?

  9. #29
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,386

    Default

    Yes, DRM like digital rights management.

    Video decoding isn't the greatest fit with the kind of work stream processors can do, or at least nobody has figured out how to find sufficient parallelism in the decoding workload to take real advantage of the shader power. Having said that, there's a big difference between inefficient and impossible.

    The biggest issue, I think, is that we do use the shaders pretty heavily for the rendering part of the playback pipeline so I'm not sure how much shader horespower is left on the 2400/2600 anyways.

    Good question though...

  10. #30
    Join Date
    Jul 2007
    Location
    Stockholm, Sweden
    Posts
    49

    Default

    I thought DRM was implemented though encryption of the encoded video data? So, to play DRM protected video, the stream has to be (roughly):

    1) Unencrypted
    2) Decoded
    3) Rendered

    Is this not right? If it is right, what is the problem with implementing 2) and 3) in the oss driver? (A pointer to a document explaining the problem would be appreciated, if such exist.)

    I can see one other reason not to release the specs for video hw decoding on a system that is not able to play DRM'd material: it would raise the demand for undamaged material even more, thus making it even more popular to download movies in a sane format over, say, bittorrent.

    *rant*

    This whole thing is just sick - why not release the movies in an open, playable format that people can USE? I and many, many others would gladly pay for it!

    *rant off*

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •