Announcement

Collapse
No announcement yet.

Revenge On Reverse Engineering

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

  • #31
    Originally posted by bitnick View Post
    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*
    If that pisses you off, get this: the new wireless connectivity standard for DVD players and TVs is limited to a range of a few feet due to MPAA pressure so that your neighbors won't be able to pick up what movie you're watching:

    Comment


    • #32
      Well broadcasting a vga signal is always a security flaw when the display could show "interesting" infos. But lets compare that to HDCP. Just for the sake of hardware vendors you have to use a vga card and monitor/tv with HDCP. You absolutely gain nothing over pure DVI. And the only thing you could avoid is that you could not record the signal with a hd capable recorder. As the protection of hd dvd/blueray is already broken and could be even removed on the fly with a commericial tool a standard DVI connector would be enough. So what would you buy...?

      Comment


      • #33
        Originally posted by bitnick View Post
        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.)
        The problem is depressingly simple. UVD handles #1 and #2 in the same block, and a lot of the setup operations are common between the functions. We haven't found a way to open up the info you need for #2 without also opening up #1.

        Implementing #3 in the open source driver won't be a problem once the 3d framework is up and running, since we use shaders for #3 in the R5xx and higher chips. We are also planning to enable use of the parts of #2 which have not yet been moved into UVD.
        Last edited by bridgman; 07 January 2008, 08:08 PM.
        Test signature

        Comment


        • #34
          Originally posted by bridgman View Post
          The problem is depressingly simple. UVD handles #1 and #2 in the same block, and a lot of the setup operations are common between the functions. We haven't found a way to open up the info you need for #2 without also opening up #1.

          Implementing #3 in the open source driver won't be a problem once the 3d framework is up and running, since we use shaders for #3 in the R5xx and higher chips. We are also planning to enable use of the parts of #2 which have not yet been moved into UVD.

          well, if you could release information on how to setup the block for unencrypted streams you would not be in violation of anything while still allowing the open source driver the benefit of the UVD :-)

          Comment


          • #35
            r300 - r400 opengl stuff

            I myself am not too concerned about hardware accelerated video decoding right now. Someday it would be nice, but my AMD X2 4200 can handle most of the video out there right now. However I would love to see enough documentation to finish up the opengl 1.3 that is currently in the driver for smoothline, and a few other miscellaneous incomplete implementations that are being covered by the low impact fall back. I would also see enough documentation to finish up to at least opengl 2.0 or 2.1 so that the latest games will work with the opensource driver. After those opengl extensions were implemented then the driver could be optimized to be the fastest open driver however it is not easy reverse engineering. It takes a lot of patience (I've tried before) a little intuition to see how the device behaves with certain commands. Many more hours tweaking trying, and so having the information would allow the driver to be completed a lot quicker than it is currently being worked on. Also reverse engineering can require a considerable amount of resources since passing a bad command can let the smoke out. Most of the time these devices are engineered so that letting the smoke out is not likely to happen, but not every case can be tested and engineers are still human.

            I'd really love smoothline and a better way to get the command buffer to play nicely so that Google Earth will play more nicely with the open driver. fglrx is fast, but unstable and has a few bugs that the open driver does not have. The open driver is stable except it isn't complete.

            Comment

            Working...
            X