Alliance for Open Media codecs [Archive] - Page 41

soresu

11th January 2020, 03:51

Xhe-aac didn't steal anything. The biggest video platform YouTube uses opus not he-aac. Second. We no longer live in 56k modem era to care that much about audio compression. 64kbps opus already sounds better than old MP3 128kbps joint-stereo. I really do not care If xhe-aac will achieve the same quality at even lower bitrate (48kbps). The same can be seen with image compression. Ancient jpg is still good enough and file size is not a problem when you have at least 1Mbps connection

Sadly even in developed countries there are plenty of rural areas with terrible data connections using ancient ADSL tech on lines miles from the nearest telephone exchange.

In less developed countries the problem is even worse still, so even a few dozen kilobits still count.

The coming satellite broadband internet solutions will likely diminish the problem somewhat globally, but even then the content providers are still thinking in terms of millions to billions of served video and audio streams/files per day - from which even 64 kbps will accumulate quickly, so they will continue to push the advancement in compression on all fronts too, simply to reduce what they have to pay for serving their content.

soresu

11th January 2020, 05:46

I think xHE-AAC has stolen Opus's thunder, since the licensing and code is free for any AAC licensee. Plus it outperforms Opus some.

Opus is getting on a bit, and represents only an early stab at using ML in audio codecs - I think we might expect the current focus on ML techniques with AV2 and VVC to bear fruit in a new audio codec sooner or later.

The xiph site called "Monty's Demo Pages" has an article about a "Real-Time Wideband Neural Vocoder at 1.6 kb/s Using LPCNet", I think done by JM Valin who also worked on Daala and AV1.

Link here (https://people.xiph.org/~jm/demo/lpcnet_codec/).

Whether this turns into anything concrete is uncertain, but it is certainly interesting.

Atak_Snajpera

11th January 2020, 12:13

In less developed countries the problem is even worse still, so even a few dozen kilobits still count.
Seriously? Do you really think that saved 16kbps will change anything? IT is 2020 . Mobile network 3g is already fast enough for 64kbps audio streaming. Audio streaming is no longer a problem. Video on other hand is a different story...

IgorC

11th January 2020, 20:26

Sadly even in developed countries there are plenty of rural areas with terrible data connections using ancient ADSL tech on lines miles from the nearest telephone exchange.

Nowdays You get at least ~ 1-1.5 Mbit in worst case or you get nothing. And that's with an old ADSL2+. 10% of that bitrate budget will go for audio. That's 128 kbps.

xHE-AAC is very low bitrate format and it doesn't present any advantage at 96 kbps and higher comparing to an old LC-AAC. (go check official MPEG tests).

In less developed countries the problem is even worse still, so even a few dozen kilobits still count.

No.
https://ispspeedindex.netflix.com/country/india/

Somebody saying that xHE-AAC is gaining market fast and letting another audio formats in dust, it isn't just not true. It's a bald-face lie.

Companies don't want to pay for low bitrate xHE-AAC license simply because LC-AAC patents have expired and they don't need to stream 32-48 kbps where xHE-AAC would make sense.

Spotify (web app), Tidal , Apple Music, Netflix, they all don't need to pay anymore for LC-AAC licensing.

xHE-AAC was developed 7 years ago. Since then it has faced stiff competition from Opus and patent expiration of MP3, LC-AAC, Dolby Digital AC3 formats. Today it belongs same place as another failed audio format, MPEG Surround, which hasn't seen any meaningful adoption.

Atak_Snajpera

11th January 2020, 23:04

xhe-aac is just another variant optimized for speech
https://www.youtube.com/watch?v=yArrLvMYng8

benwaggoner

13th January 2020, 21:09

Seriously? Do you really think that saved 16kbps will change anything? IT is 2020 . Mobile network 3g is already fast enough for 64kbps audio streaming. Audio streaming is no longer a problem. Video on other hand is a different story...
There are hundreds of millions of people in developing countries who often connect with 2G. And streaming video is streaming video + audio, so every bit saved from audio means the minimum bitrate for AV is that much lower.

If you're talking rural mobile delivery, saving 16 Kbps from audio really does make a material difference.

This is why lower speed mobile in developing countries might be one of the most viable markets for AV1, since it truly is a lot better than H.264 for very low bitrates. Of course, that is dependent on getting performant SW decoders or HW decoders on low-cost devices. Which often run an ASOP derivative versus actual Google-endorsed Android with all those requirements. If we see low-cost chipsets with HW AV1 become ubiquitous, that would be a big market that has rapid turnover for new models.

benwaggoner

13th January 2020, 21:24

Nowdays You get at least ~ 1-1.5 Mbit in worst case or you get nothing. And that's with an old ADSL2+. 10% of that bitrate budget will go for audio. That's 128 kbps.
For a household, maybe. For those who have that connection. But that gets shared across multiple users, and probably neighbors too.

xHE-AAC is very low bitrate format and it doesn't present any advantage at 96 kbps and higher comparing to an old LC-AAC. (go check official MPEG tests).
"Not better, but lower bitrate" is a pretty big advantage. Plus xHE allows for seamless audio bitrate switching, which wasn't possible between LC/HEv1/HEv2.

https://ispspeedindex.netflix.com/country/india/
Obviously Netflix customers are pre-selected as people who have enough bandwidth to stream Netflix.
The Netflix ISP Speed Index is a measure of prime time Netflix performance on particular ISPs (internet service providers) around the globe, and not a measure of overall performance for other services/data that may travel across the specific ISP network.

Somebody saying that xHE-AAC is gaining market fast and letting another audio formats in dust, it isn't just not true. It's a bald-face lie.
It's getting built into the major OSes and mobile platforms already. There is no extra cost to add it for anyone who is already a Fraunhofer AAC SDK licensee. Whenever someone updates to the recent version, they'd have to comment out xHE in order to not support it. And it's pretty trivial for anyone doing adaptive streaming to offer multiple audio codecs to support backwards compatibility.

Companies don't want to pay for low bitrate xHE-AAC license simply because LC-AAC patents have expired and they don't need to stream 32-48 kbps where xHE-AAC would make sense.

Spotify (web app), Tidal , Apple Music, Netflix, they all don't need to pay anymore for LC-AAC licensing.
Citation that they don't pay for it? There's no royalty for any of that per hour streamed or something like that. The cost of AAC licensing is really immaterial.

xHE-AAC was developed 7 years ago. Since then it has faced stiff competition from Opus and patent expiration of MP3, LC-AAC, Dolby Digital AC3 formats. Today it belongs same place as another failed audio format, MPEG Surround, which hasn't seen any meaningful adoption.
MPEG Surround has been supplanted by MPEG-H, which is the default ATSC 3.0 codec in many markets, including South Korea. It's increasingly built into mass market devices. And Android has had it built in for a while now.

MPEG-H is really an Atmos/AC-4 competitor, though; not for low bitrate stereo. I see it growing a lot in living room devices, less in North America than in Asia.

benwaggoner

13th January 2020, 21:29

xhe-aac is just another variant optimized for speech
https://www.youtube.com/watch?v=yArrLvMYng8
I don't know about "just." It's a codec that supports both speech-focused and general-purpose encoding tools, and can mix and match those as is most appropriate for bitrate and content. It's really the same concept as Opus, with the same strengths.

The big difference is that it fits into the existing audio codec and MPEG ecosystems better. Not that Opus had any fundamental technical reasons why it couldn't, but there just weren't proponents pushing for it the same way and with the same resources.

Web/PC oriented technologies can innovate quickly and powerfully, but it's way harder to migrate from there to consumer electronics and living room than people imagine. Same reason why VP8/9 never had much traction outside of user generated content on the web. Premium content interoperable across all material endpoints requires a huge, huge effort from many, many stakeholders.

IgorC

13th January 2020, 21:35

There are hundreds of millions of people in developing countries who often connect with 2G
Those hunders of millions of people don't use their 2G connection to watch Netflix (to begin with)! In fact most of these people care more about an access to drinking water rather than to high speed internet connection. Netflix isn't priority there.

More advanced codecs like HEVC, VP9, AV1, Opus, xHE-AAC won't bring possibility to use services like Netflix or Spotify on 2G or 3G as such limited speeds and, most importantly, traffic cap make these services hardly affordable for people with low incomes in developing countries.

Also there is no terrific difference bettween speed of developed/developing countries https://ispspeedindex.netflix.com/

It doesn't support your theory of 2G in developing countries. :rolleyes:

Atak_Snajpera

13th January 2020, 21:53

IgorC

13th January 2020, 22:24

@Atak_Snajpera
+1

MPEG Surround has been supplanted by MPEG-H...
How does it change the fact that MPEG Surround hasn't seen meaningful adoption?

MPEG Surround is standard since 2007 as MPEG-H is since 2015.

So a period of supplantation took 8 years (?) Ben, really?

soresu

13th January 2020, 22:48

MPEG-H is really an Atmos/AC-4 competitor, though; not for low bitrate stereo. I see it growing a lot in living room devices, less in North America than in Asia.

You put Atmos and AC-4 in the same place there.

Is AC-4 the coding scheme for all Atmos? Or is that just for web streams using Atmos?

birdie

14th January 2020, 01:04

Is this a topic about AV1? I'm not sure I'm at the right forum.

Perhaps some people want to continue here: https://hydrogenaud.io/index.php?board=54.0 ;-)

skal

14th January 2020, 10:17

There are only two I can think of
[LIST]
despite being technically more advanced you can still lose to a decades old legacy format when your encoder is terrible

Do you have a concrete example? Why is the encoder terrible?

it does not matter that your format is worse than the legacy competition,

Sample?

Seriously the only area where it might be a tiny bit better is for ultra-high compression where it does not start falling apart as badly as jpeg, for any sane (mid ot high) image quality range the vast array of jpeg encoders are doing a significantly better job of retaining detail

Could be it because you're trying to recompress an already jpeg-encoded source? (aka, spurious resonance). This seems like an overly broad statement, otherwise.

skal/

Tadanobu

14th January 2020, 17:21

Those hunders of millions of people don't use their 2G connection to watch Netflix (to begin with)! In fact most of these people care more about an access to drinking water rather than to high speed internet connection.

Exactly! People in those countries do not give a f about some streaming services If you have nothing to eat and drink!
Not to even mention about Electricity...

Guys, I don't mean to be rude but you really sound like people who do not know much about these countries and these people. I live in Madagascar and I don't quite agree with you.

You will find people in very remote places with no water and no electricity but with phones. Not necessarily smartphones, but with an access to 2G/3G/4G. It's widely used to communicate, send money and other stuff. There are small, cheap solar panels to easily charge these phones. Also, a part of the internet is free. Depending on your ISP, you'll have free access to Facebook, Wikipedia and other sites. Most of the time, there are restrictions like no images or no videos. Believe me, there are many many young people who will just buy some credit/data as soon as they have money. They won't buy food or water because these people don't buy food or water. They grow their own food and fetch water at the well or the river. Pocket money is mostly for entertainment so they will buy cigarettes, candies or whatever.

Anyway, back on topic. In the big cities, you have great connections. I'm working 160km South from the capital city and I have 4G+. But as soon as you leave the biggest area, you end up with 2G and sometimes no network at all. And people love streaming here. Well, they have no TV, no newspaper, no nothing. But they have a phone and an access to internet. Of course they want to see pictures and watch videos. Not Netflix of course, but Facebook is absolutely huge, Youtube is not very important here. The real problem here is the cost of the data. It's damn expensive. Browsing text can be fairly inexpensive. Images are quite expensive. Video is really a rich people thing. Personally, I'm not poor but I disable all images when I browse the internet. And I can't afford more than a few minutes of videos per week. Also, keep in mind that people don't care about quality at all. They don't want better quality for same size, they want same quality at lower bitrate, so they can save data and therefore money. So AV1 will be very very useful. Easier to stream in remote areas, less expensive, allowing better quality... Africa, South-East Asia and other areas are big markets that are growing a lot. Hardware is way behind, but apart from that it's all the same (selfie sticks, filters, nomophobia... you name it). It doesn't concern 100% of the population yet, but for the younger generation it's already a wide majority.

benwaggoner

14th January 2020, 22:32

Those hunders of millions of people don't use their 2G connection to watch Netflix (to begin with)! In fact most of these people care more about an access to drinking water rather than to high speed internet connection. Netflix isn't priority there.
There are absolutely lots of people watching premium video over 2G networks. The experience isn't great, but it can be better than not being able to watch anything.

More advanced codecs like HEVC, VP9, AV1, Opus, xHE-AAC won't bring possibility to use services like Netflix or Spotify on 2G or 3G as such limited speeds and, most importantly, traffic cap make these services hardly affordable for people with low incomes in developing countries.
Perhaps not in theory, but it is in practice :sly:! Replacing AAC-LC at 96 Kbps with xHE-AAC at 24 Kbps is a whole extra 64 Kbps to either lower minimum bandwidth requirements or increase video bitrate.

Also there is no terrific difference between speed of developed/developing countries https://ispspeedindex.netflix.com/
Self selected to people using Netflix. Netflix has substantially higher minimum bitrates compared to some other services, particularly those local to lower-bandwidth regions. That said, people in developed countries still ride in subways or are in rural areas, so being able to ramp down to very low bitrates with a "better than nothing" experience on mobile devices is valuable worldwide.

AV1 proponents should hope this is a viable market, because it's probably where AV1 would have the biggest differential advantage over H.264 and a market where rapid turnover and Android-centric mobile markets could result in >50% HW decoder installed base by 2025.

Nintendo Maniac 64

15th January 2020, 03:52

LG announced (http://www.lgnewsroom.com/2020/01/lg-to-unveil-2020-real-8k-tv-lineup-featuring-next-gen-ai-processor-at-ces-2020/) that their new 8K TVs will support AV1.

As far as I know these are the first TVs with AV1 hardware decoding. I wonder if they will also support Opus.

These TVs will feature quite powerful SoCs and Opus is a very low complexity codec, so I see no reason not to support it.

Besides, YouTube started using it years ago along with VP9 and each device which supports YT must support Opus by default.

I think he may have meant ASIC support?

As you say it's low complexity so it wouldn't require an ASIC to run it in a wall powered device like a high end 4K TV, but anything that reduces thermal output is welcome, it's annoying hearing a fan coming from a TV.

I'm a bit late on this, but I was able to confirm from a family friend with an E9 TV that the 2019 LG OLEDs already support VP9+Opus WebM files played from a USB HDD.

And decoding complexity isn't always the reason for lacking format support because I was also able to confirm that, while the 2019 E9 OLED also supports VP8 + vorbis in a WebM as well as VP9 + AAC in an MKV, it does not support VP8 + AAC in an MKV.

Here's the full list of tested formats and combinations that I was able to confirm that worked (all video codecs are 8bit unless otherwise noted):

AVI: Xvid + MP3
AVI: AVC + MP3
MKV: HEVC + AAC
MKV: VP9 + AAC
MP4: AVC + AAC
MP4: Xvid + AAC
MP4: Xvid + MP3
WebM: VP8 + Vorbis
WebM: VP9 + Opus
WebM: VP9 + Vorbis

And the things that didn't work (all video codecs are 8bit unless otherwise noted):

MKV: VP8 + AAC
MKV: AVC 10bit + FLAC
MP4: AV1 (video only)
WebM: AV1 + Opus

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 (though this logic doesn't apply to the MKV with VP8 + AAC as it's able to support all 3 things in other combinations, just not together).

EDIT: I've since confirmed 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.

benwaggoner

15th January 2020, 23:52

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 (though this logic doesn't apply to the MKV with VP8 + AAC as it's able to support all 3 things in other combinations, just not together).
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.

hajj_3

17th January 2020, 10:12

new rav1e build is out: https://github.com/xiph/rav1e/releases/tag/p20200115

nakTT

22nd January 2020, 18:27

new rav1e build is out: https://github.com/xiph/rav1e/releases/tag/p20200115
Hi, do we have GUI for this encoder? Something like MeGUI or anything? Thank you in advance.

paul97

22nd January 2020, 18:48

https://moisescardona.me/rav1e-gui/
https://ffmpeg.zeranoe.com/builds/

Download rav1e gui.
Download the static ffmpeg with the date. (exe)
Copy the ffmpeg in rav1e gui folder that you extracted (with 7-zip or winrar).
Disable pipes (right at the centre that is a checkbox). If it causes problems.
It still could have different aspect ratio and different framerate not PAL (.vob file) 23.9976
It supports anything with ffmpeg, and ffmpeg converts to yuv. Pipes are to not generate .yuv file.
For a GUI there is also Hybrid GUI (with aomenc - svt appveyor you can download) and Svt GUI, the last by Moises (same developer as rav1e gui).

nakTT

22nd January 2020, 19:22

paul97

22nd January 2020, 19:32

https://www.reddit.com/r/AV1/comments/bnn184/where_find_latest_av1_build/
I asked the question on Reddit some months ago. Here it is.

nakTT

22nd January 2020, 19:38

https://www.reddit.com/r/AV1/comments/bnn184/where_find_latest_av1_build/
I asked the question on Reddit some months ago. Here it is.
Thanks for the reply.

I'm starting the encoding process now.

Thanks again.:thanks:

paul97

22nd January 2020, 21:39

You're welcome.
Rav1e has still 80% 120% 340% difference in quality/bitrate in videos on arewecompressed.yet AWCY. A site that codec developers use to test. SVT is too far from libaom as encoder if you see Mrsmilingwolf's user test on Reddit or on Doom9 like comparable to VP9 a bit not better. I don't know if he tests with anime or like action.

Also FFmpeg has included a build of encoders (Libaom) which you check the readme file in the archive (.zip) or in lower section "Other Downloads" by clicking Readme to see which version it is. Handbrake GUI doesn't support the encoding because it's too slow and AV1 support it's only in beta.
But it supports dav1d (Videolan) decoding, only 8bit is completed on general SIMD, 10 bit lacks support, so it runs without SIMD instructions.
If you use a GUI like Hybrid other than ffmpeg, to encode with libaom you will need aomenc.exe.
Artificial noise isn't possible with a GUI, you need ffmpeg and use libaom.

benwaggoner

23rd January 2020, 00:47

You're welcome.
Rav1e has still 80% 120% 340% difference in quality/bitrate in videos on arewecompressed.yet AWCY. A site that codec developers use to test.
What do those percentages mean specifically?

SVT is too far from libaom as encoder if you see Mrsmilingwolf's user test on Reddit or on Doom9 like comparable to VP9 a bit not better. I don't know if he tests with anime or like action.
Given the configurability of SVT-AV1 in terms of quality/perf and tuning, it's hard to know what to make of encoder versus encoder comparisons. There are literally dozens of values that could impact quality. It would be more useful to compare quality at known best parameters, or quality at same bitrate and encoding time on a given system config.

It seems that there should be scenarios and highly multicore systems where SVT-AV1 would beat libaom in quality @ bitrate @ perf, just because it would have so many more MIPS/pixel available.

user1085

31st January 2020, 04:15

Thank you so much for the reply.

How do I check that I get the latest AV1 encoder?

Thank you in advance.https://www.singhkays.com/blog/docker-image-av1-ffmpeg-libaom/

I compile a docker image with the latest libaom source + ffmpeg every weekend

soresu

5th February 2020, 21:10

Optimisation for dav1d happening for 16 bpc on ARM64 apparently - whether that means everything between 16 and 8 I don't know.

Apparently Netflix are pushing out AV1 now too (possibly even sponsoring the new optimisation efforts?).

Are we finally at the point where AV1 deserves its own sub forum?

hajj_3

6th February 2020, 00:07

https://netflixtechblog.com/netflix-now-streaming-av1-on-android-d5264a515202

dapperdan

6th February 2020, 01:08

Optimisation for dav1d happening for 16 bpc on ARM64 apparently - whether that means everything between 16 and 8 I don't know.

Apparently it means code written for both 10 and 12 bit at the same time, but since they don't fit into 8 bit, they jump to 16.

Nintendo Maniac 64

6th February 2020, 05:02

Is YouTube starting to roll out AV1 for less popular videos and/or YouTubers?

I noticed AV1 encodes on the following video with less than 100k views that's only 5 days old: https://www.youtube.com/watch?v=g6NvMpzRoyU

Also I always found it a bit odd that YouTube used MP4 rather than WebM for AV1. I realize MKV and therefore WebM support was not available when YouTube started introducing AV1, but considering they themselves created WebM (albeit not from scratch as it's a derivative of MKV), and they previously chose to use WebM rather than MP4 for VP9 tells me that they would prefer WebM when given the choice...

(personally I greatly prefer the WebM and by extension MKV container vs MP4 when it comes to streaming assuming the codec used is the same, but I realize that for 99.9999% of people WebM/MKV vs MP4 container would make absolutely no impact on how they consume video)

Blue_MiSfit

6th February 2020, 06:38

Probably wider support for fMP4 on various platforms. What benefits does WebM offer over fMP4 for ABR streaming via DASH?

Nintendo Maniac 64

6th February 2020, 10:06

What benefits does WebM offer over fMP4 for ABR streaming via DASH?

So the following is a super niche use-case... (this is even why I specifically said "99.9999%" to 4 decimal places rather than the more typical "99.9%" or "99.99%", because I'm fully aware just how super niche this use-case is).

I notice that opening an incomplete DASH MP4 stream in MPC-HC or mpv that is downloading via youtube-dl will have the video stream eventually stop at whatever point the video had downloaded when you launched the file even if the download is finished (thereby requiring you to relaunch the video).

With YouTube's DASH WebM encodes though, if you open an incomplete but still downloading DASH WebM video in MPC-HC or mpv, it's able to completely play through the video without issue as long as it's downloading quicker than you're viewing it.

It is worth noting however that sometimes I notice that a rare DASH WebM video will instead be downloaded into individual chunks via youtube-dl which are then reassembled into a single file as it downloads. These are notable in that trying to watch the reassembled albeit still downloading video gives you the exact same behavior as the DASH MP4 videos.

birdie

6th February 2020, 10:06

Is YouTube starting to roll out AV1 for less popular videos and/or YouTubers?

I noticed AV1 encodes on the following video with less than 100k views that's only 5 days old: https://www.youtube.com/watch?v=g6NvMpzRoyU

720p only. 1080p is still distributed using VP9.

https://netflixtechblog.com/netflix-now-streaming-av1-on-android-d5264a515202

This announcement makes no sense: I don't know a single mobile SoC which supports AV1 HW decoding acceleration right now which means the poor users who will watch AV1 content will decimate their battery life.

Nintendo Maniac 64

6th February 2020, 10:09

720p only. 1080p is still distributed using VP9.

1080p AV01 (fmt 399) is listed in youtube-dl though and does indeed successfully download.

I don't know a single mobile SoC which supports AV1 HW decoding acceleration right now which means the poor users who will watch AV1 content will decimate their battery life.

I would imagine they're probably only using it for SD, likely with a focus on markets where bandwidth speed and the like is quite low (think maybe less than 1mbps?)

birdie

6th February 2020, 10:12

1080p AV01 (fmt 399) is listed in youtube-dl though and does indeed successfully download.

Yet both Google Chrome and Mozilla Firefox defaulted to VP9 when I switched to 1080p.

Nintendo Maniac 64

6th February 2020, 10:15

Yet both Google Chrome and Mozilla Firefox defaulted to VP9 when I switched to 1080p.

Perhaps YouTube is "holding back" on playing more than 720p AV1 in browsers because they know that no hardware decode support is available on PCs?

They did something similar back when they were rolling out VP9 whereby it would fallback to AVC if your user agent listed Windows XP (one of the few cases of user agent sniffing that I feel is not actually terrible)

Also here's a youtube-dl screenshot for reference showing the 1080p AV1:

https://archive.is/E7aDh/da109c997e6ecad3a0d2914d7c566f8272c8577f.png

Funky080900

6th February 2020, 10:44

Yet both Google Chrome and Mozilla Firefox defaulted to VP9 when I switched to 1080p.

I get 1080p AV1 in Firefox on Windows

birdie

6th February 2020, 11:17

I get 1080p AV1 in Firefox on Windows

Are you sure about that?

Firefox 72, UA: Windows 10 64: https://i.imgur.com/nkZRiUZ.png

Are_

6th February 2020, 11:42

Am I sure?
https://imgur.com/WG8icgu

Jokes aside that's probably a setting somewhere on the YouTube account, I kind of remember something like that.

birdie

6th February 2020, 11:52

Am I sure?
https://imgur.com/WG8icgu

Jokes aside that's probably a setting somewhere on the YouTube account, I kind of remember something like that.

Yeah, and I didn't touch it (https://www.youtube.com/account_playback), so in terms of defaults YouTube does not yet offer AV1 for 1080p videos.

benwaggoner

7th February 2020, 19:20

Probably wider support for fMP4 on various platforms. What benefits does WebM offer over fMP4 for ABR streaming via DASH?
Exactly. There's SO much stuff for MP4 as a container format, and such a huge infrastructure around it. WebM just doesn't have the same ecosystem or any particular standout features.

benwaggoner

7th February 2020, 19:25

This announcement makes no sense: I don't know a single mobile SoC which supports AV1 HW decoding acceleration right now which means the poor users who will watch AV1 content will decimate their battery life.
Has anyone looked at what the power draw of AV1 decode looks like on different devices/platforms. Like using a Kill-a-watt on a charged laptop or a desktop and comparing AV1 playback versus a HW decoded bitstream?

Obviously there is a lot of other power draw happening for the screen, UX, system. But getting a delta would be helpful.

Back in the day with Silverlight, I remember finding the HW decoder could save 20 watts over the SW decoder on a laptop of the era. Obviously with much less powerful CPUs than we have now, but also with a much less complex decoder (H.264 in this case).

"How many hours of playback" is an important metric for premium video content players.

Nintendo Maniac 64

7th February 2020, 21:55

Exactly. There's SO much stuff for MP4 as a container format, and such a huge infrastructure around it. WebM just doesn't have the same ecosystem or any particular standout features.

Opus does not use the MP4 container on YouTube though and does in fact use WebM.

Nevertheless, follow-up question.

As someone that has no concept of what goes into the software back-end required for delivering video, does it in fact still improve the ease of implementation to use a container that is already widely used if it's a completely new codec anyway?

Blue_MiSfit

7th February 2020, 23:20

Yes, it does, because you still have to package it (and encrypt it, often). There's often an established ecosystem to do this in a way that meets business requirements. Sometimes it's even done dynamically. Adding support for a new codec in that tooling is likely easier than having to implement support for a whole new container format as well.

Same thing on the clients, honestly. I don't see anything about WebM that adds value to the adaptive streaming use case, but I may be missing something.

benwaggoner

8th February 2020, 02:19

Same thing on the clients, honestly. I don't see anything about WebM that adds value to the adaptive streaming use case, but I may be missing something.
And media format code is pretty low level, so needs to get lots of fuzz testing and security checks. People remember how often big security bugs (Stagefright for example) come from media playback stacks.

So there's little desire to take on new code for such mission critical task.

Nintendo Maniac 64

8th February 2020, 09:35

foxyshadis

8th February 2020, 11:01

So yeah uh...then why the heck are they using WebM for Opus? I mean, isn't splitting the video and audio between separate MP4 and WebM containers even worse than just having both in a WebM container let alone both in an MP4 container?

The whole point of DASH is that you can cherrypick your favorite video and audio, and swap in alternates at any time depending on bandwidth. You can swap languages without having to download all languages. The container they're delivered in doesn't matter, but they still need something. That necessitates that every stream is packaged separately, but fortunately, WebM/MKV and MP4 are very low-overhead containers. The penalty is well under 1% for most videos.

I think there's a combination of institutional inertia in keeping Opus on WebM instead of tearing down the whole stack, and that no one wants to be the guy who accidentally broke YouTube while changing it over.