Log in

View Full Version : Alliance for Open Media codecs


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 [42] 43 44 45 46 47 48 49 50 51 52

MoSal
8th February 2020, 13:54
I think Instagram were already shipping a VP9 software decoder on Android I don't think they were even using the fast ffmpeg decoder, just libaom.


Ouch, that's just being bloody minded to user battery life that is.


Not really. libvpx (not libaom) has good NEON optimizations and performs much better than ffvp9 on ARM.

hajj_3
8th February 2020, 17:58
rav1e 0.3.0 has been released: https://github.com/xiph/rav1e/releases/tag/v0.3.0

soresu
8th February 2020, 20:33
Not really. libvpx (not libaom) has good NEON optimizations and performs much better than ffvp9 on ARM.

Ah my mistake, I took it as a given the ff**** decoders were usually better optimised.

Also didn't realise that libvpx had another incremental version in december - v1.8.2 "Pekin Duck".

Does libaom have official version names/numbers yet?

utack
9th February 2020, 19:23
Does anyone know why libaom and vmaf are not compatible on an arch linux system?

cmake ../aom -DCONFIG_TUNE_VMAF=1


make
home/jakob/Downloads/aom/aom_dsp/vmaf.c:13:10: fatal error: libvmaf/libvmaf.h: No such file or directory
13 | #include <libvmaf/libvmaf.h>

pacman -Ql vmaf | grep libvmaf
vmaf /usr/include/libvmaf.h

so if I edit it to #include <libvmaf.h> it builds, but why is the path different than what libaom asks for?

SmilingWolf
10th February 2020, 17:42
Does anyone know why libaom and vmaf are not compatible on an arch linux system?

Packaging differences. Compiling from sources and using "ninja -vC release install" puts the header(s) under <somewhere>/include/libvmaf/<headers>.h
Arch's package maintainer probably follows in the footsteps of the Debian package (https://debian.pkgs.org/10/multimedia-main-amd64/libvmaf-dev_1.3.14-dmo3_amd64.deb.html), that leaves the header under /usr/include/libvmaf.h

SmilingWolf
11th February 2020, 18:30
Anyway, the last time (~18 months ago) I tried linking libvmaf to ffmpeg, I got runtime crashes after I managed to find a version that compiles. So I figured the library is not really reliable API/ABI wise for external linkage use-cases. So I opted to just script around the provided executable vmafossexec.

The timeframe look just about right to be about https://github.com/Netflix/vmaf/issues/177, which has since been fixed by http://ffmpeg.org/pipermail/ffmpeg-devel/2018-August/233012.html

hajj_3
12th February 2020, 00:43
Samsung galaxy s20 has been announced, no mention of AV1 support which i'm a little surprised at.

nevcairiel
12th February 2020, 00:48
Samsung galaxy s20 has been announced, no mention of AV1 support which i'm a little surprised at.

Its Android 10, at the very least it has a built-in software decoder.

Otherwise, its just Snapdragon 865, we already knew its media support - which does not include AV1. It won't be in the mainstream until the end of the year, if not 2021.

Blue_MiSfit
12th February 2020, 01:44
Yeah, ooof. At least yet another cycle in front of us before we see a premium mobile phone with hardware AV1 decoding.

Blue_MiSfit
13th February 2020, 06:04
Surely streaming only low bitrate SD, with just acceptable quality (since it's a low bandwidth opt-in feature).

Still, a great fit for davi1d!

sneaker_ger
13th February 2020, 13:09
Cool that they seem to go 10 bit even for mobile. It's time companies start to see 10 bit as a coding tool increasing compression instead of using it for HDR only. I would hope they start using AV1 10 bit for desktop, too. I'm temporarily on a slow (5~6 Mbps) connection and there can be horrible banding (among other artifacts) when viewing via Chrome (I assume H.264 8 bit).

utack
13th February 2020, 20:59
I have finished three encodes matching up "vmaf_without_preprocessing" against x265 placebo, and I am completely stunned.
The new vmaf tuning has definitely put libaom in first place not only in metrics but clearly in visual quality!
I hope they will manage to speed it up in the future

benwaggoner
13th February 2020, 21:43
Surely streaming only low bitrate SD, with just acceptable quality (since it's a low bandwidth opt-in feature).

Still, a great fit for davi1d!
There's no HW DRM for AV1 on any mobile device yet, so premium content above SD would presumably not be allowed in any case.

Blue_MiSfit
14th February 2020, 03:45
Interesting, correct me if I'm wrong but it's not really a matter of DRM "supporting AV1" as much as it is AV1 having a defined mapping into fMP4 with common encryption (CENC), right? Once that's all set then any DRM that supports CENC would work, be it software Widevine L3 or hardware Widevine L1 or PlayReady SL3000 etc?

Is that mapping still really not done for AV1??

Mr_Khyron
14th February 2020, 13:07
AVIF for Next-Generation Image Coding
https://netflixtechblog.com/avif-for-next-generation-image-coding-b1d75675fe4
TL; DR
We need an alternative to JPEG that
a) is widely supported
b) has better compression efficiency and
c) has a wider feature set. We believe AV1 Image File Format (AVIF) has the potential.
Using the framework we have open sourced, AVIF compression efficiency can be seen at work and compared against a whole range of image codecs that came before it.

Blue_MiSfit
14th February 2020, 18:46
That was a great posting, tbh. AVIF shows serious advantages over WebP which I think is the only JPEG alternative format that's gotten any traction on the web from what I can tell.

dapperdan
16th February 2020, 00:31
That was a great posting, tbh. AVIF shows serious advantages over WebP which I think is the only JPEG alternative format that's gotten any traction on the web from what I can tell.

JPEG XL is a strong contender. It seems to have buy in from a similarly diverse set of implementors as AV1, but one key advantage is that it can seamlessly and losslessly upgrade existing JPEG content, which would probably make it attractive to web deployment even if it didn't offer anything else. If it's well integrated with HTTP2 and browsers then progressive loading is a second "killer app" it provides and again that alone could probably justify its rollout as the subjective improvement in partial loading display would be dramatic even if the objective improvements were equal or even negative.

benwaggoner
16th February 2020, 19:09
Interesting, correct me if I'm wrong but it's not really a matter of DRM "supporting AV1" as much as it is AV1 having a defined mapping into fMP4 with common encryption (CENC), right? Once that's all set then any DRM that supports CENC would work, be it software Widevine L3 or hardware Widevine L1 or PlayReady SL3000 etc?

Is that mapping still really not done for AV1??
The mapping is done. But it is really challenging to robustly secure a software-only decoder. It can be done in Trust Zone, but not all devices allow full CPU use for that. And there is still more risk SW being hacked; so much fuzz testing from malformed bitstreams is required, and DRM robustness competes with decode for compute optimization.

Major studios generally require HW DRM integrated with HW decoders for premium HD content. And lots of platforms straight up doing allow their SW codecs to use the HW DRM features. For example, iOS has HEVC software decoders for all device supported by the iOS version that introduced HEVC playback. But FairPlay DRM straight up won't work on the device without the HW decoder.

benwaggoner
16th February 2020, 20:00
JPEG XL is a strong contender. It seems to have buy in from a similarly diverse set of implementors as AV1, but one key advantage is that it can seamlessly and losslessly upgrade existing JPEG content, which would probably make it attractive to web deployment even if it didn't offer anything else. If it's well integrated with HTTP2 and browsers then progressive loading is a second "killer app" it provides and again that alone could probably justify its rollout as the subjective improvement in partial loading display would be dramatic even if the objective improvements were equal or even negative.
HEIF is also a good contender here, and is very well supported in the Apple ecosystem at least. Mostly as HEVC frames. That's the default way to shoot pictures on iPhones now.

But HEVC and patents. AV1 is a strong still image codec, and the patent exposure elminating all the interframe stuff is even smaller. Screen coding tools. And SW decode is a lot more feasible for just images, and DRM is rarely a requirement for them too.

Broad AVIF support in browsers seems like something that could happen quite quickly, and be of use with much less infrastructure than video. A PhotoShop export component and integration into ImageMagick and we'd be ready to go.

Blue_MiSfit
16th February 2020, 21:40
Broad AVIF support in browsers seems like something that could happen quite quickly, and be of use with much less infrastructure than video. A PhotoShop export component and integration into ImageMagick and we'd be ready to go.

Seems like a great fit, agreed. Dynamic server-side versioning of images with tools like ImageMagick is a common thing, so this would indeed be an easy win.


Major studios generally require HW DRM integrated with HW decoders for premium HD content

Yep! I work for one of them ;)


FairPlay DRM straight up won't work on the device without the HW decoder

I actually didn't realize this, but it totally makes sense.

marcomsousa
20th February 2020, 17:14
rav1e 0.3.1 released

25-40% faster speed levels 2 to 5
This is accomplished by disabling costly coding tools
**Fine directional prediction
**Intra block transform splitting in inter frames
Encoding quality is slightly inferior (1-2%), but more in line with the target speed levels


https://github.com/xiph/rav1e/releases

Nintendo Maniac 64
23rd February 2020, 09:53
Unfortunately I didn't provide a test file that combined AVC 10bit and FLAC with other known-working codecs, like AVC 8bit + FLAC as well as AVC 10bit + AAC, so it's uncertain whether it's the AVC 10bit or the FLAC that the TV is unable to play back.

That's the thing about consumer electronics devices. The only way to really know if something works is to actually try it. Something can support all the individual components, but not in particular combinations. Something may work via streaming or an app but not as a file in the native player. Everything might work most of the time except if some esoteric parameter exceeds some internal limit even though it is permitted by the spec.

Something that works on a thing is easy. Something interesting that works on EVERYTHING is a nail-biting adventure.


Apologies for the off-topic post, but I just wanted to give an update on the final conclusion - I just confirmed today that FLAC audio is in fact supported (at least up to 192KHz 24bit, same goes for LPCM as 32float LPCM failed to work) and, as expected, it's the 10bit AVC (not a typo) that is completely unsupported on LG's 2019 OLEDs.


...though more surprising to me was that it not only supported multi-audio MKVs/MP4s with an according GUI-based audio track switcher, but even supported freaking SubStation Alpha subtitles in an MKV also with an according GUI-based toggle.


That is all, and I will refrain from going on about this subject farther.




BTW SmilingWolf, if you're reading this, I got to watch our waifu2x-upscaled UBW Vita OP the LG E9 OLED TV (65" model).

10/10 would recommend.

sneaker_ger
24th February 2020, 00:17
No AV1 with Tiger Lake? I get that right?

foxyshadis
24th February 2020, 07:25
No AV1 with Tiger Lake? I get that right?

Big delays might open an opportunity to add a decoder, but otherwise, it's going to be implemented in gpu, not fixed-function. It'll look the same to software, it just won't perform the same.

Nintendo Maniac 64
24th February 2020, 09:31
Apologies for the delayed response and for another somewhat off-topic post, but it was only just now that I came across a video with the according WebM-in-chunks formatting that I previously mentioned in this thread and I didn't think it'd be wise to make a whole new thread for a discussion that will probably last all of like two posts.

Try passing --youtube-skip-dash-manifest to youtube-dl.

This does not seem to work on the following video's 1080p VP9 encode:

https://www.youtube.com/watch?v=K60qpDSSnJU

(assuming that I'm not doing something wrong of course, which is always a possibility)

nevcairiel
24th February 2020, 12:22
It'll look the same to software, it just won't perform the same.

Historically, those have been entirely unusable, especially from Intel. So I hope they won't waste their time on it.

MoSal
24th February 2020, 19:33
Apologies for the delayed response and for another somewhat off-topic post, but it was only just now that I came across a video with the according WebM-in-chunks formatting that I previously mentioned in this thread and I didn't think it'd be wise to make a whole new thread for a discussion that will probably last all of like two posts.



This does not seem to work on the following video's 1080p VP9 encode:

https://www.youtube.com/watch?v=K60qpDSSnJU

(assuming that I'm not doing something wrong of course, which is always a possibility)

Yep. You get a URL that upon request returns a 404 error. Maybe that's intentional. Maybe not. We would know for sure if their backend stops spitting such URLs.

Or it could be some boring reason, like the video server requiring certain headers, or the server is, for some reason, tied to a specific old quic/http3 draft. Who knows.

Well, at least audio/Opus unfragmented streams still work.

hajj_3
26th February 2020, 12:19
AOM newsletter: https://aomedia.org/wp-content/uploads/2020/02/AOMedia-Non-Member-Newsletter-February-2020-upadated.pdf

mzso
27th February 2020, 11:56
Yes.



Could you elaborate on what sort of system (CPU chipset etc.), and where you got the content from? In particular, it'd be interesting to know the respective bitrates for the AV1 & VP9 files/streams, but knowing the encoder settings might also be somewhat useful.

Playback speed correlates a lot with bitrate. The 30% numbers that we've shown at conferences and in blogs are for same-quality encodes, where VP9 has a higher bitrate than AV1. If the files are same-bitrate, the performance difference goes up. On easy content, the postfilters also require a higher % of runtime (compared to e.g. inverse transform or predictors), and since AV1 has more postfilters, that means the difference will grow on low-complexity content, and will be smaller on high-complexity content. The 30% was also without film grain (since we assume the GPU will do that for free), but there is currently no browser that does that correctly yet.

(I have a Ryzen 5 1600, with a B350 board)


I just played youtube videos, with AV1 enabled and disabled, nothing scientific.
But roughly that's what I experienced in cpu usage use.

Beelzebubu
27th February 2020, 14:34
(I have a Ryzen 5 1600, with a B350 board)

What browser/version, and on what platform/OS?

I just played youtube videos, with AV1 enabled and disabled, nothing scientific.
But roughly that's what I experienced in cpu usage use.

I think Youtube is known to do significantly higher bitrates for AV1 than for VP9, so that could be part of why...

benwaggoner
2nd March 2020, 01:49
I think Youtube is known to do significantly higher bitrates for AV1 than for VP9, so that could be part of why...
Really? Do you have any documentation?

This would be odd since a key point of AV1 is to be able to use lower bitrates than VP9. And as a performance-heavy SW decoder, lower bitrates help performance as well.

Toggleton
2nd March 2020, 11:31
Really? Do you have any documentation?

This would be odd since a key point of AV1 is to be able to use lower bitrates than VP9. And as a performance-heavy SW decoder, lower bitrates help performance as well.

https://www.reddit.com/r/AV1/comments/dxqr8k/answer_to_why_av1_videos_on_youtube_use_higher/

But i think that is not true anymore. Have seen more mixed results and av1 was most of the time smaller.
Will look, if we can collect data about it once new AV1 encoded videos are available(no new AV1 encoded video since 2020-02-23 in the "Popular Right Now" playlist)

Tracker how many AV1 encoded videos are in the "Popular Right Now" playlist per day
https://htmlpreview.github.io/?https://github.com/thulle/yt-av1/blob/master/yt-av1.html

utack
2nd March 2020, 21:11
AOMedia Member Spotlight with Netflix’s Manager, Android Player Infrastructure, Jeff Watts (http://aomedia.org/aomedia-member-spotlight-with-netflixs-manager-android-player-infrastructure-jeff-watts/)

marcomsousa
2nd March 2020, 23:51
AOMedia Member Spotlight with Netflix’s Manager, Android Player Infrastructure, Jeff Watts (http://aomedia.org/aomedia-member-spotlight-with-netflixs-manager-android-player-infrastructure-jeff-watts/)I am most excited to see AV1 appear in the mobile chipsets. With hardware support, we can start pushing our AV1 support into higher resolutions. Because we have an AV1 pipeline ready, we are in a good position to help evaluate this hardware as it becomes available. I look forward to sharing our learnings with the first AV1 hardware when it comes out.

Marco Sousa

benwaggoner
3rd March 2020, 00:48
https://www.reddit.com/r/AV1/comments/dxqr8k/answer_to_why_av1_videos_on_youtube_use_higher/

But i think that is not true anymore. Have seen more mixed results and av1 was most of the time smaller.
Will look, if we can collect data about it once new AV1 encoded videos are available(no new AV1 encoded video since 2020-02-23 in the "Popular Right Now" playlist)

Tracker how many AV1 encoded videos are in the "Popular Right Now" playlist per day
https://htmlpreview.github.io/?https://github.com/thulle/yt-av1/blob/master/yt-av1.html
I can see that making sense. Given how YouTube distributes encoding, it would be hard to run AV1 at higher quality/efficiency levels with libaom. So at the same MIPS/pixel, they may have needed to use a higher bitrate than with vp9 to deliver the higher quality they wanted to with AV1. Which makes sense as their goal was to push AV1, not to use it to deliver lower bitrate or higher quality content overall (then they would have just raised vp9 bitrates).

As we're getting faster and better encoding, I would expect the AV1 bitrates to drop while maintaining quality.

Blue_MiSfit
6th March 2020, 02:02
Excellent! Good to see more comprehensive 10+ bit optimization being done. This is mandatory for HDR :)

benwaggoner
10th March 2020, 22:45
Excellent! Good to see more comprehensive 10+ bit optimization being done. This is mandatory for HDR :)
Yeah, fast ARM 10-bit will make HDR feasible on 2020 mobile devices. For user generated content at least; premium studio content will still require HW DRM.

It's be nice to have some benchmarks with details beyond "Up to 2.5x faster" - is that only in some edge cases, or is ~2x speedup a practical expectation?

nevcairiel
10th March 2020, 23:21
The optimizations covered quite a lot of very commonly used functions (MC, Loopfilter, CDEF), so I would expect quite decent improvements for the majority of clips. I believe a proper announcement with example benchmarks is still being worked on.

NikosD
11th March 2020, 17:27
It also brings new AVX-512, AVX2 and SSSE3 optimizations and improves the existing optimizations on all platforms.Insignificant gains for 8 bit video according to Phoronix for modern CPU architectures.
Probably that's why they didn't announce performance differences from previous versions as they always do.
But huge gains for 10 bit video, as they actually begin optimizations for this colour depth for the first time, starting with this version.

motbob
14th March 2020, 00:32
I discovered a quirk of aom that might be of interest to some people.

Sometimes keyframes in aom look really bad even in constant quantizer mode and a cq level of 20. Examples: https://slow.pics/c/GaddIUgb

I believe this happens when the encoder looks ahead and sees that the keyframe (or parts of the keyframe) is pretty useless because not a lot depends on it.

You can fix these low quality keyframes, if you want, with --enable-keyframe-filtering=0. Obviously, this will use more bitrate.

IgorC
14th March 2020, 17:59
Netflix - SVT-AV1: an open-source AV1 encoder and decoder (https://netflixtechblog.com/svt-av1-an-open-source-av1-encoder-and-decoder-ad295d9b5ca2)

hajj_3
16th March 2020, 22:19
AMD's new 7nm zen2 based ryzen 4000 'renoir' laptop chips were announced today, they don't support AV1 :(

image: https://images.anandtech.com/doci/15624/2%20AMD%20Ryzen%20Mobile%20Tech%20Day_General%20Session_Architecture%20Deep%20Dive-page-009.jpg

marcomsousa
16th March 2020, 22:53
Zen2 based...
Also AMD is always slow on HW codec, or instructions.

Is much more important on the next mobile SoC.

Marco Sousa

hajj_3
17th March 2020, 00:01
Zen2 based...
Marco Sousa

Zen 2 based doesn't require them to use any specific video decode block. They can release zen 2 chips with a newer video decode block that can decode av1.

soresu
17th March 2020, 05:07
Zen 2 based doesn't require them to use any specific video decode block. They can release zen 2 chips with a newer video decode block that can decode av1.

Unlikely, the 'Renoir' 4000 series APU with Zen2 cores is likely to be the last major design with Zen2, with following low cost and embedded designs likely to be derivative.

It seems likely that the Zen3 based Cezanne APU (like 5000 series) will have AV1 decoding blocks, perhaps maybe the new discrete GPU's expected later this year too.

nevcairiel
17th March 2020, 09:30
Media features are typically part of the GPU, not the CPU, as such Zen2 or Zen3 wouldn't make the key difference, but the Vega graphics on them would - which isn't even RDNA yet, so its rather old.

NikosD
17th March 2020, 12:31
Renoir SoC has a special version of Vega at 7nm that has borrowed multimedia engine from Navi aka RDNA.

We have to actually run DXVAChecker to see real features and decoding speed.

marcomsousa
17th March 2020, 18:39
OnePlus 8 Lite will support AV1 HW decode.

The normal or the PRO version doesn't because Qualcomm do not support it.

https://uploads.tapatalk-cdn.com/20200317/336a0c4c2f62f9be392066cf5b90aa1b.jpg

Marco Sousa

utack
18th March 2020, 10:51
What is Qualcomms deal at this point?
Are they silently preparing another Patent Pool for AV1 like Sisvel, or are they just lazy and indecisive

hajj_3
18th March 2020, 18:31
new macbook air has been released, it uses a 10th gen intel processor, no info about AV1 decoding or not: https://www.apple.com/uk/macbook-air/specs/