Looking Forward To UVD On Linux?

[phoronix]

Phoronix: Looking Forward To UVD On Linux?

After slides had leaked out onto the Internet last month that AMD is going to support playing high-definition multimedia content on Linux, we had talked a bit more about UVD for Linux. There are two shared libraries already shipping with the AMD Catalyst Linux Suite, libAMDXvBA.so.1.o and libXvBAW.so.1.o, that reference XvMC and UVD2 (Unified Video Decoder 2) but they aren't yet being utilized by the proprietary driver...

http://www.phoronix.com/vr.php?view=Njc1Ng

[Odur]

Well, I personally don't care about HD video as long as the proprietary driver makes my computer go into a hard lock when I try to switch users (HD3870). Shutdown works as it should, but switching users just freezes the whole thing. I have to use the radeonhd driver instead :/

Wouldn't it be better if they ironed out the big bugs before introducing new features?

[Mr. Anderson]

It is probably a good idea to make UVD an open standard, as it then has chances to become the standard that is everyone expecting to be implemented by every vendor. That way AMD can take the lead in this discipline...

[DeepDayze]

Sounds like a nice feature to implement to allow HD video playback..would be nice for others such as nVidia and Intel to implement for their cards as well

[kuse]

What is the difference between this and the VA-API ?

[VaHyper]

This sounds nice!
Good movie playback is more important than good 3D acceleration to me.

[tmpdir]

yaha... can't wait to drop this baby on my Mythbuntu (MythTV) media center.

[dashcloud]

What's going to be the player(s) that use UVD? Considering it's not available currently, none of the open-source projects can pick it up- so unless AMD is releasing their own player app (or a partner is), it will be some time before anyone can actually use it,

[_txf_]

Hmm .. I doubt that this acceleration architecture will be available to mythtv or mplayer etc due to drm. They are going to require their own player to guarantee a protected path, and seeing as it can't be done in the kernel for obvious reasons, then thats what will happen.

This is going to have some oem bundled proprietary playback software, so no fun for anyone trying to use this on worthwhile apps like myth...

maybe useful, but not as much as it could be.

[dashcloud]

Hmm .. I doubt that this acceleration architecture will be available to mythtv or mplayer etc due to drm. They are going to require their own player to guarantee a protected path, and seeing as it can't be done in the kernel for obvious reasons, then thats what will happen.

This is going to have some oem bundled proprietary playback software, so no fun for anyone trying to use this on worthwhile apps like myth...

maybe useful, but not as much as it could be.

The protected path + what Bridgman's mentioned about UVD vs. UVD2 design makes me believe that UVD1 card owners will be left out at the beginning.

[jeffro-tull]

wait, so, does this mean they finally fixed the tearing issues? Because, frankly, it doesn't matter what definition the video is if the graphics drivers tear it apart before it hits the screen.

[DeeZiD]

wait, so, does this mean they finally fixed the tearing issues? Because, frankly, it doesn't matter what definition the video is if the graphics drivers tear it apart before it hits the screen.

Hopefully... :)

[liels]

wait, so, does this mean they finally fixed the tearing issues? Because, frankly, it doesn't matter what definition the video is if the graphics drivers tear it apart before it hits the screen.

That was my first thought and the thing most important to me by far. My 2nd thought is that if there's an api that is callable from gcc (like CUDA) then some really nice general purpose number crunching could be enhanced by this. Or maybe not.

[DeepDayze]

Hmm .. I doubt that this acceleration architecture will be available to mythtv or mplayer etc due to drm. They are going to require their own player to guarantee a protected path, and seeing as it can't be done in the kernel for obvious reasons, then thats what will happen.

This is going to have some oem bundled proprietary playback software, so no fun for anyone trying to use this on worthwhile apps like myth...

maybe useful, but not as much as it could be.

Or perhaps a specially modified version of myth/mplayer to access the protected stream securely

[tmpdir]

Good point... Currently looking for well balanced choices of hardware for MythTV to include in the manual togehter with a few chapters on DVB (satellite and cable). I'm very interested in the answer on this topic.

By the way, I don't think they need their "own" player to guarantee a protected path,there are other sollutions possible.

Maybe bridgman can clarify this?



Hmm .. I doubt that this acceleration architecture will be available to mythtv or mplayer etc due to drm. They are going to require their own player to guarantee a protected path, and seeing as it can't be done in the kernel for obvious reasons, then thats what will happen.

This is going to have some oem bundled proprietary playback software, so no fun for anyone trying to use this on worthwhile apps like myth...

maybe useful, but not as much as it could be.

[mirak63]

wait, so, does this mean they finally fixed the tearing issues? Because, frankly, it doesn't matter what definition the video is if the graphics drivers tear it apart before it hits the screen.

what makes you think this ?

[ayumu]

wait, so, does this mean they finally fixed the tearing issues? Because, frankly, it doesn't matter what definition the video is if the graphics drivers tear it apart before it hits the screen.
I hope so. I own a HD4850 and atm xv means tearing, which is a pain. As a workaround, opengl has vsync, so mplayer works fine with -vo gl and -vo gl2; been watching movies like that for a while.

[_txf_]

Or perhaps a specially modified version of myth/mplayer to access the protected stream securely

Nope, as far as I'm aware mplayer and myth are licensed under GPLv2 which states that if you distribute the software you're required to post the source code with the changes included, completely defeating the purpose of the protected path...