Radeon VCN Video Decode Support Lands In Mesa

[phoronix]

Phoronix: Radeon VCN Video Decode Support Lands In Mesa

AMD developers have landed their work on supporting VCN video decoding in Mesa. VCN is the new video decode engine with the upcoming Raven Ridge APUs (Zen CPU + Vega Graphics) that apparently succeeds the UVD video decoding block...

http://www.phoronix.com/scan.php?page=news_item&px=VCN-Video-Decoding-Mesa

[Nille]

Support for AMDs De- and Encoder in ffmpeg for Windows and Linux would make me more happy. Quicksync is there (with libmfx) nvenc (and cuvid for decoding) is there but AMD is missing.

[VikingGe]

Sadly, no sign of VP9 or other open-source codecs.

That's probably because the industry does not and will never care for open-source codecs. Just look at audio codecs. MP3 is the default for pretty much anything, with the "hot new stuff" actually being AAC. Not Opus, not even Vorbis which has been around for well over a decade, no, it's AAC. And if not for Google, nobody would care about VP9 either (except for MPEG-LA, I doubt they would allow an open codec that could actually compete). Intel at least seem to have hardware support for VP9.

Support for AMDs De- and Encoder in ffmpeg for Windows and Linux would make me more happy. Quicksync is there (with libmfx) nvenc (and cuvid for decoding) is there but AMD is missing.

AMD should theoretically be covered by vaapi already. That said, I never managed to actually make it work.

[Adarion]

There is some support for freedom codecs in the industry. E.g. Cowon offers portable music players for years now and those were advertised to be a) Linux compatible (MTP or USB mass media switchable) and b) play OGG-Vorbis and even FLAC. So that's a good thing (and reason why I bought their stuff). There are also others, even though it should be more, of course.
On the VCN side, well, who knows. What is sent upstream now is code for things that previous generations could already do. But maybe they have something else ready to sent but they're waiting for a corporate announcement before they submit something that would reveal future capabilities.

And here +1 for better and direct support for AMD encoders (and partially decoders, though that seems to work nice most times via VDPAU) in ffmpeg, handbrake and the likes.

[Nille]

AMD should theoretically be covered by vaapi already.

That's not a real solution. Its only limited to Linux and it has its own Problems. The easiest solution would be OpenMax in the Windows Driver with De- and Encoding capability.

[DrYak]

That's probably because the industry does not and will never care for open-source codecs. Just look at audio codecs. MP3 is the default for pretty much anything, with the "hot new stuff" actually being AAC. Not Opus, not even Vorbis which has been around for well over a decade, no, it's AAC.

That entirely depends of the direction you're looking to.

- If you mean "the Radio TV industry, etc." : yeah they're pretty much entrenched with everything that comes out of MPEG/ISO standards.
(Modern TV, Bluray, etc. all rely on MPEG-2 or H264/MPEG4 AVC video and AAC, DTS, AC3 for audio. DAB is Mpeg Layer II, DAB+ is AACplus).

- But if you look at *everything that works online today*, OPUS is the king. It's a IETF standard, you find it available on most browsers, and on most portable devices, and for the rest, there's 100% guaranteed no patent license, permissive licensed code.
And because of that, you'll find OPUS in Skype (well obviously, they collaborated with Xiph making it), in WhatsApp, in lots of web apps, etc. chances are: if it's something you use for voice chat, it's probably running on OPUS.

The exception ? Spotify. What do *they* use ? Vorbis. (The previous patent-free, permissive codec that was widely supported in browsers back when aspotify was started).

in fact even Digital Radio Mondial (the digital cousin of AM radio) is getting in-official standards to support OPUS.

The reasons of the above ?
- Patent license (OPUS and Vorbis are completky free : no patent license, free permissive code. MP3 used to be license by Frauenhoffer. AAC is still licensed, at least for codec developpers)
- Quality (back then Vorbis was better than MP3 and WMA. Nowadays OPUS beats nearly everything with only few exceptions (e.g.: < 4k bit/s) that don't actually matter for internet.

There is some support for freedom codecs in the industry. E.g. Cowon offers portable music players for years now and those were advertised to be a) Linux compatible (MTP or USB mass media switchable) and b) play OGG-Vorbis and even FLAC. So that's a good thing (and reason why I bought their stuff). There are also others, even though it should be more, of course.

Tons of no-name asian manufacturer actually support vorbis on their device, it's just badly advertised.
(It's easy to add, given that there are good interger-only permissively licensed implementations).

(It used to be, at some point in the past, that the device manufacturer didn't mention Vorbis loudly intentionally, because to obtain the "Plays For Sure" certification, it had to support explicitely MP3, WMA, and nothing else.)

Vorbis is even supported on some big name asian devices.
(It's a IETF standard anyway).

Sadly, no sign of VP9 or other open-source codecs.

On the other hand, AMD are member of AOMedia, so maybe we'll see code that implements some parts of AV-1 in the future.

@VikingGe:

That's another upcoming IETF standard, similar to OPUS and Vorbis.

AOMedia has membres who are hardware maker (AMD, Intel, ARM, Nvidia), content provider (Netflix, Google), browser provider (Google, Mozilla, etc.)
All the big names that cover a huge chunk in the market are here around.
That gives promises for future support.

(And it's probably going to be similar to OPUS : TV and Bluray aren't going to switch over to AV-1.
But within a year from now, probably that any online website or smartphone APP that deals with video will be using AV-1.
Video chat in WhatsApp and co. And nearly any web site that deals video.)

[juno]

Support for AMDs De- and Encoder in ffmpeg for Windows and Linux would make me more happy.

You can use it with ffmpeg, through va-api and vdpau.

That's not a real solution. Its only limited to Linux and it has its own Problems. The easiest solution would be OpenMax in the Windows Driver with De- and Encoding capability.

Why is it no solution? It works and supporting the relevant APIs for a platform is the right thing to do, imho. They support dxva on Windows. The only problem I've encountered is the limited capabilities of the actual hardware, which is obviously independent from the supported API.


Concerning VCN: if this thing is a completely new block and no more UVD it would be a shame if there is no VP9 support. They claimed it for Polaris already and it was only a hybrid solution that never worked on Linux. And who the hell needs VC1?

[dkasak]

That's probably because the industry does not and will never care for open-source codecs. Just look at audio codecs. MP3 is the default for pretty much anything, with the "hot new stuff" actually being AAC.

I was pleasantly surprised when I put a CD full of ogg files into my Honda and it played. This is of course the exception - most of the industry is as you say.

[Adarion]

But within a year from now, probably that any online website or smartphone APP that deals with video will be using AV-1.
Video chat in WhatsApp and co. And nearly any web site that deals video.

A year is a bit optimistic. First there needs to be implementation in SW, and that is quite a lot and we all know that a lot of projects take some time to include certain new features. Moreover you probably want to have it done correctly. The other missing part is HW acceleration, and this will spread even slowe. E.g. one-chip systems, APU-soldered boards etc. can't just add this functionality. And sometimes you really dearly want HW acceleration for a video codec (I recently tried x265, it was impressive with filesize/quality ration but en- and decoding ate quite a lot of CPU). So until any praised new codec hits the streets in the real world a lot of water will flow down the river.

[Nille]

Why is it no solution?

Because you ignore the Encoding Part. If you decode only on the hardware and encode on the cpu you benefits are to small.

And who the hell needs VC1?

For BD Support you need it.