3D Optimizations and UVD... AMD_hal.so!

[popper]

sure Bridgman, i just put it up for clarity, and the mention of nvcuvid/vdpau kind of brings us back to the OPs point a closed yet documented binary blob from ATI to do all the things and more that the NV sub API cuda ASIC also does...

[bridgman]

For linux it is vdpau.

You might be right -- the API looks like it should allow application read access to a VdpVideoSurface.

VDPAU was already released when folks were still complaining about the lack of a frame-at-a-time decoding API though, and at least one poster mentioned that VDPAU wouldn't work for their application because it was "one way". Doesn't look that way from the API spec though...

[Kano]

Well i know that it works with mplayer and xinelib as i use both.

[bridgman]

Yep, for straight playback I don't think there's any question.

Popper was talking about frame-at-a-time decode with application read-back in earlier threads, however.

[popper]

yep, the requote i put in the first page

http://www.phoronix.com/forums/showpost.php?p=61565&postcount=9

covered that "frame accurate" app editing point.

in essence, its the basis for all your AVCHD video edited work flows and the like, its a shame (or perhaps not? if the review fails)the potential AVIVO Encoding/Transcoding/muxing part isnt using the UVD HW, OR IS IT?, or at least the Encoding parts included in some ATI API , something like the Kdenlive HD video editor project http://www.kdenlive.org/ could make very good use of these two parts from inside FFMpeg.

BTW Carl Eugen Hoyos on the FFmpeg dev list is the one working the VDPAU FFmpeg patchs...

[duby229]

2. If you want Linux market share to grow, enough to drive native app and game development for example, you're going to need things like legal BD playback with the associated DRM support. That implies a bottom-to-top closed source solution; open source drm implementations are being discussed but I don't think anyone has a practical implementation yet. Until the "what does Linux want to become ?" discussions settle down (if ever) I don't think it makes sense to take the driver in a direction (closed source 3D mixed with open source modesetting) where we would have to completely discard in order to deliver a secure legal BD solution.

All I have to ssay about that is..... Bullshit....

Whether you guys ;like it at ATi or not DRM --WILL-- be cracked. And despite all the work you guys have put into fighting it, I will be able to watch commercial BD movies on my open source operating system with open source drivers and open source players with out a single line of DRM code.

It's going to happen.

[energyman]

that drm might be cracked does not change the fact that AMD and NVIDIA (and INTEL, Microsoft) are bound by CONTRACTS and associated LAWS.

Earth to duby229, laws and contracts have to be followed. If you like them or not.

[yotambien]

All I have to ssay about that is..... Bullshit....

Whether you guys ;like it at ATi or not DRM --WILL-- be cracked. And despite all the work you guys have put into fighting it, I will be able to watch commercial BD movies on my open source operating system with open source drivers and open source players with out a single line of DRM code.

It's going to happen.

Yeah...and since no matter what assasinations are going to happen, I guess the sensible, logical, practical thing to do is to hand guns to everybody.

[curaga]

yotambien, good ol' America has done that for years now

[duby229]

that drm might be cracked does not change the fact that AMD and NVIDIA (and INTEL, Microsoft) are bound by CONTRACTS and associated LAWS.

Earth to duby229, laws and contracts have to be followed. If you like them or not.

None of which effect the Linux market AT ALL. What ATi NEEDS to do is simply say that we are not interested in providing any support for BD playback on linux. Period. Instead what we will do is release information about our hardware to the public that will enable you to develop your own entirely independent implementation, of which we hold no liability for. Limitations to this documentation include but are not limited to any hardware that is required for restricted playback of protected content. In such cases where that information about that hardware can lead to playback of restricted content it will not be made available.

It means that any implementation that is made will be made independently from ATi, and they will have no liability for it. It would be kinda like you hacking into the Iranian Embassy and Novell getting blamed for it because you used there OS....

This scenario is entirely possible, and would probably already have happend if ATi would have dropped fglrx year and a half ago.