I don't think embedding the OS in ROM removes the obligation to provide source. AFAIK TIVO provides source for the kernel changes distributed with their system.
What folks refer to as "Tivoization" is a bit different AFAIK -- that's when the software is upgradeable but a mechanism is used so that only software from the vendor (or another approved source) can be used for the replacement.
No, it's the entertainment industry that is retarded they need to revise their business model. Restricting consumers is not the way to go, people just go download the freaking movies in matroska files.
Originally Posted by RealNC
Yes, that's exactly what I'm talking about. The only way I can see Linux qualifying for "authorized" BD playback is if the player software and the rest of the stack is tied to an "approved" locked-down kernel binary or a whitelist of such binaries.
Originally Posted by bridgman
And as far as a lot of people are concerned (including some important kernel developers and, less importantly, myself), such a system wouldn't be Linux anymore.
Y'know, there's a lot more of us consumers out here than there are people working in the entertainment industry. If enough people cared about this issue, we ought to be able to petition for repeal of a lot of these laws. But so far, average joes don't seem to care (or understand, or something) about how DRM infringes on their rights.
the whys and whatfors of DRM seem to be a side issue here,people just want to use the ASIC for HW assisted decoding/Encoding/Transcoding of their (re-)encoded HD videos at the end of the day.
the implication is, that the ATI UVD/UVD2 ASIC block has in fact some form of DRM inside it, and that is the reason Bridgman and ATI/AMD are having problems and not providing the headers/docs in a timely manor, were as the NV etc dont seem have this DRM inside their ASIC (or just dont reference any of that potential DRM part?)and so have a large commercial video assitance advantage here....right now.
if so why did this DRM block get put there instead of its own self contained block for far better security ?, is it really so hard to simply not reference any of this DRM block inside the real important UVD video decoding block headers and documentation everyone wants to see and perhaps use ?.
is it really so hard for the internal UVD ASIC devs and doc writer to simply make a headerfile that just references the video options we want to use as per FFMpeg patchs etc , and write their operation entry/exit points up in a PDF, and spend a day compiling their existing test code that doesn t have any conection to any DRM that may or not be inside that ASIC.
if not then at least get some internal ATI devs to write a full subset API, and provide working code that can replace this virtually useless UVD ASIC due to the DRM inclusion there, on the other parts of the GFx cards.....
put simply, if infact there is DRM inside the UVD ASIC, and so making it almost useless to external devs that want to use everything in it except that potential DRM block, then simply say so and move on, learn the lesson and dont include your DRM block in the next UVD ASIC revision (see an FPGA would have been a very good reprogramable thing here Bridgman )
Last edited by popper; 02-05-2009 at 05:34 PM.
What I'm saying is "our top priority is the hardware we said we would open up", ie enough for 2d, 3d and Xv acceleration. That's getting close to being finished now, so some time over the next couple of months I hope to be able to start looking at UVD to see whether it is feasible to open up some hardware info without putting DRM at too much risk.
NVidia has only provided support for their hardware in a closed source driver (like us) so I don't understand your comment about NV not having DRM in their hardware. The distinction here AFAIK is simply that NVidia have made their closed source solution more broadly available than we have, and that they have provided a Windows library for decoding single frames which has been picked up for use in transcoding apps.
Windows library? CUDA is available for Linux too. If you use it tricky you can even run win CUDA apps with wine!
well OC i dont know if NV have included any DRM inside their ASIC, all people care about is NV are giving people somethng ATI could be giving too but currently dont, ATI and the OEMs sold the X1xxx, HD2xx ,HD3650,HD4xxx on the premise of real HW assisted video playback and real AVIVO GFx card HW assisted AVC Encoding etc, its all still only CPU bound and run after all this time, no apparent use of the UVD ASIC even on windows!.
its also been said (by the developer relations *manager of genesi)that any 3rd party devs/companies relying on ATI/AMD UVD/UVD2 plans to base a product on are mad/insane to do so.....
i and many others want you to do well in the HW assisted video space, OC, otherwise why would i/we be posting here, just so thats clear
*"Fri Jan 16, 2009 Matt Sealey,(Neko),Site Admin,Genesi, Manager, Developer Relations said:
There is no driver, not even in the binary ones, ATI will not give a schedule for it and may only expose it through a custom "XvBAW" API.
This is not going to get you playing videos right now and it would be insanity to develop a product around it.
We recently finished off a marketing requirements/product requirements document for something, and one of the things we agreed to cut out completely was support for an ATI graphics chip (the E2400) because there are no open-source 3D drivers for RV680 and waiting for them to get stable, or commissioning a binary driver in lieu of that, would not be cost-effective"
Last edited by popper; 02-05-2009 at 06:35 PM.
Just because I disagree with you on specifics doesn't mean I don't appreciate what you are trying to do
Kano, the discussion is not about CUDA itself but a specific library provided for use with CUDA, called nvcuvid. That is what uses the video decode hardware to decode a frame and return the contents to the application. As far as I can see, nvcuvid is Windows only right now.