Alliance for Open Media codecs

[marcomsousa]

Mozilla released today Firefox 63

Firefox 63 adds an AV1 decoder (it's disabled by default).


To try AV1:

• Update your stable Firefox (installer)
• Enable AV1: about:config?filter=media.av1.enabled pass the alert message and enable av1 then restart Firefox
• Go to the YouTube TestTube page.
• Select "Prefer AV1 for SD" or "Always Prefer AV1" to get the desired AV1 resolution. Note that at higher resolutions, AV1 is more likely to experience playback performance issues on some devices.
• Try playing YouTube clips from the AV1 Beta Launch Playlist.
• Confirm the codec av01 in "Stats for nerds".

[hajj_3]

Firefox 64 Beta is out, which i think enables AV1 by default.

UPDATE: I don't think it is enabled by default, this video won't play: http://video.1ko.ch/codec-comparison...18-06_550.webm

[Pushman]

https://www.bunkus.org/blog/

Here is MKVToolNix v28.0.0: the first release to support AV1 in its finalized form. mkvmerge can read it from Matroska/WebM, MP4, IVF container files and from raw OBU streams. mkvextract will extract it to IVF files. Apart from that a couple of bugs were fixed and usabitliy enhancements made.

New features and enhancements for AV1:

• mkvmerge: AV1 parser: updated the code for the finalized AV1 bitstream specification. Part of the implementation of #2261.
• mkvmerge: AV1 packetizer: updated the code for the finalized AV1-in-Matroska & WebM mapping specification. Part of the implementation of #2261.
• mkvmerge: AV1 support: the `--engage enable_av1` option has been removed again. Part of the implementation of #2261.
• mkvmerge: MP4 reader: added support for AV1. Part of the implementation of #2261.
• mkvextract: added support for extracting AV1 to IVF. Part of the implementation of #2261.

[Mosu]

Originally Posted by sneaker_ger

Btw: MkvToolNix 28.0.0 now with finalized support for AV1 reading/writing in mkv/webm.

Originally Posted by Pushman

https://www.bunkus.org/blog/

Note that the sequence header parser code in mkvmerge v28 was buggy. Those issues have been fixed since. If you want to use mkvmerge/MKVToolNix for AV1, you should use the latest continuous builds (Windows, Linux AppImage) instead.

[PatchWorKs]

Hi everyone, I'm trying to understand how to obtain the better quality/speed/size for FHD/3 (aka 360p or, more precisely, 640x*) resolution videos @ 1 Mbps.

Since AV1 (but other codecs too) supports multiple bitdepth do you suggest to use 12 ?
About chroma: choosing 444 instead of 420 could help to obtain better quality ?

Thanks in advice for anyone can help.

[alex1399]

Apply moderate De-grain, De-noise, Sharpen and more would help the visual quality. Some encode enhancer have friendly GUI to work around if you have video card.

[M4ST3R]

Originally Posted by marcomsousa

Mozilla released today Firefox 63

Firefox 63 adds an AV1 decoder (it's disabled by default).


To try AV1:

• Update your stable Firefox (installer)
• Enable AV1: about:config?filter=media.av1.enabled pass the alert message and enable av1 then restart Firefox
• Go to the YouTube TestTube page.
• Select "Prefer AV1 for SD" or "Always Prefer AV1" to get the desired AV1 resolution. Note that at higher resolutions, AV1 is more likely to experience playback performance issues on some devices.
• Try playing YouTube clips from the AV1 Beta Launch Playlist.
• Confirm the codec av01 in "Stats for nerds".

It doesn't work me. The youtube testtube page says the AV1 codec is not available in my browser yet.
I use firefox 63 and I have enabled media.av1.enabled

[benwaggoner]

Originally Posted by PatchWorKs

Hi everyone, I'm trying to understand how to obtain the better quality/speed/size for FHD/3 (aka 360p or, more precisely, 640x*) resolution videos @ 1 Mbps.

Since AV1 (but other codecs too) supports multiple bitdepth do you suggest to use 12 ?

Higher will make encoding and decoding slower. I wouldn’t use >8-bit unless working with a source that is >8-bit with >8-bit detail.

About chroma: choosing 444 instead of 420 could help to obtain better quality ?

444 gives you 24-bit per pixel instead of 12-bit. Making some naive assumptions, one could expect that to double encoding and decoding time. And most progressive content is totally fine with 4:2:0 sub sampling. The exception is if you have very sharp edges between saturated colors. Like sharply rendered red text on a green background. Natural images are almost always great with 4:2:0.

Also, VBR 1 Mbps at 640x360 isn’t a very challenging bitrate; H.264 can do quite well for lots of content at that bitrate, and HEVC can do well at significantly lower. Heck, I could do a nice WMV VC-1 in those constraints a decade ago. Doing encoding tuning at a bitrate where things look good is a lot harder since subtle improvements or degradations might not be visible. Using a bitrate where it’s never going to look great makes the impact of changes more visible and more meaningful. Making mediocre quality significantly better is where differences in encoders really matter.

FWIW. I’m able to get mediocre 1920x800 out of HEVC at 1 Mbps. That’s 1/9th the bits per pixel as 1 Mbps at 640x360.

An “interesting” bitrate to compare 640x360 natural image content at would be more in the 200-500 Kbps range for VBR. If you’re doing a constant bitrate encode, higher can make sense. I’m not sure how accurate CBR rate control is in AV1, though. VP3-9 weren’t ever any good at VBV compliance.




Sent from my iPad using Tapatalk

[lvqcl]

Originally Posted by M4ST3R

It doesn't work me. The youtube testtube page says the AV1 codec is not available in my browser yet.
I use firefox 63 and I have enabled media.av1.enabled

32-bit Firefox or 64-bit one?

[Mystery Keeper]

Works for me. Sad thing is: the uploaded videos are uploaded in inferior formats so far. Re-coding into AV1 doesn't make them better. The first video I watched had color banding. But no DCT artifacts.

[marcomsousa]

The commit libaom-v1.0.0-820-g4c118dc5e enables by default CONFIG_LOWBITDEPTH=1, 8bit content optimized codepaths.

[PatchWorKs]

Originally Posted by benwaggoner

Higher will make encoding and decoding slower. I wouldnÂ’t use >8-bit unless working with a source that is >8-bit with >8-bit detail.

Yes, but - as you probably know - more bits results in better compression...

Anyway source is AVC 264 FHD 8bits 4:2:0

Originally Posted by benwaggoner

444 gives you 24-bit per pixel instead of 12-bit. Making some naive assumptions, one could expect that to double encoding and decoding time. And most progressive content is totally fine with 4:2:0 sub sampling. The exception is if you have very sharp edges between saturated colors. Like sharply rendered red text on a green background. Natural images are almost always great with 4:2:0.

Yes, I made some tests @444 and encoded videos seems - to me- less contrasted/colorful (more natural ?)...

Originally Posted by benwaggoner

Also, VBR 1 Mbps at 640x360 isnÂ’t a very challenging bitrate; H.264 can do quite well for lots of content at that bitrate, and HEVC can do well at significantly lower. Heck, I could do a nice WMV VC-1 in those constraints a decade ago. Doing encoding tuning at a bitrate where things look good is a lot harder since subtle improvements or degradations might not be visible. Using a bitrate where itÂ’s never going to look great makes the impact of changes more visible and more meaningful. Making mediocre quality significantly better is where differences in encoders really matter.

Well, the challenge is to stay under 1Gb for 2hrs of stream (audio+video) preserving quality.
Anyway I'll try @ 750Kbps to understand if it's possible to obtain acceptable results.

Originally Posted by benwaggoner

FWIW. IÂ’m able to get mediocre 1920x800 out of HEVC at 1 Mbps. ThatÂ’s 1/9th the bits per pixel as 1 Mbps at 640x360.

An “interesting” bitrate to compare 640x360 natural image content at would be more in the 200-500 Kbps range for VBR. If you’re doing a constant bitrate encode, higher can make sense. I’m not sure how accurate CBR rate control is in AV1, though. VP3-9 weren’t ever any good at VBV compliance.

I'm testing "realtime" quality encoding, so VBR is not allowed.

Here's the FFMPEG commandline I've used to test VP9:

ffmpeg.exe 
-y 
-hwaccel auto
-i "<source_filename>" 
-c:v libvpx-vp9 
-pix_fmt yuv444p12le 
-cpu-used 5 
-r 30 
-g 90 
-quality realtime 
-speed 7 
-threads 4 
-row-mt 1 
-tile-columns 1 
-frame-parallel 0 
-qmin 4 
-qmax 48 
-b:v 1M 
-maxrate 1M 
-bufsize 1M 
-sws_flags lanczos
-vf "crop=<parm>,scale=iw/3:ih/3" 
-sn 
-an 
-f webm "<output>_VP9.webm"

This performs between 30 and 50fps (depending on source complexity) on i3-4160 testing machine.

[utack]

the past ~2 weeks libaom has been producing files for me it can't decode any more, a few frames into the stream it dies and never recovers

Failed to decode frame: Corrupt frame detected
Additional information: Failed to decode tile data

dav1d is not dying, but shows a lot of blocky colorful artifarcts in many GOPs
Is that happening to everyone else or did i find a rare bug in my build proccess or encoder settings?

[Selur]

Is that happening to everyone else or did i find a rare bug in my build proccess or encoder settings?

Encoded a bunch of files last week with with up-to-date builds of aomenc and rav1e and had no problem.

[SmilingWolf]

Originally Posted by utack

the past ~2 weeks libaom has been producing files for me it can't decode any more, a few frames into the stream it dies and never recovers

dav1d is not dying, but shows a lot of blocky colorful artifarcts in many GOPs
Is that happening to everyone else or did i find a rare bug in my build proccess or encoder settings?

If you're using more than one slice and more than one thread, you've just met my old friend BUG 2054
So far I have reached the conclusion it happens (but not always!) when forcing the encoder to use columns with the width of 2 superblocks (128 pixels). Doesn't happen when the columns have a width of 256 pixels or more on the same file with all the other settings being the same.
I have been doing single threaded encodes for weeks because of this.

[hajj_3]

MPC-BE beta 1.5.3 v4106 has been released which supports AV1: https://sourceforge.net/projects/mpc...r.zip/download

[utack]

Originally Posted by SmilingWolf

If you're using more than one slice and more than one thread, you've just met my old friend BUG 2054

That might be it. Or the 10bit pipeline.
I switched to 8bit and no "threads" option and that works for now.

[benwaggoner]

Originally Posted by PatchWorKs

Yes, but - as you probably know - more bits results in better compression...

Anyway source is AVC 264 FHD 8bits 4:2:0


Yes, I made some tests @444 and encoded videos seems - to me- less contrasted/colorful (more natural ?)...

There REALLY shouldn’t be any value in using more chroma sub samples than the source! Unless you are downscaling in the same operation. A 720p 4:2:0 source’s chroma samples would be 4:4:4 at 360p.

You might want to try some kind of blind test, though. You shouldn’t see more color or more contrast with more samples. You might see sharper edges between areas of strong color. For example, with ClearType text, which plays all sorts of RGB 444 subpixel tricks that don’t translate well to even other LCD panels, let along different color spaces.

(Pro tip for doing screen recording; disable chroma subpixel rendering for text. Otherwise it can look unpredictably funky on different displays).

[Revan654]

1. With Rav1e anyone know what type -r Reconstruction takes (Boolean, String, Int, etc...) and what it actually does. I can not find any info on it and the help menu is blank for that option.

2. This has been likely asked a dozen times over, Whats the main reason why aomenc is slower compared to other encoders out there?

I'm just starting to research AV1.

[marcomsousa]

Originally Posted by Revan654

2. This has been likely asked a dozen times over, Whats the main reason why aomenc is slower compared to other encoders out there?

1. libaom it was developed for research purposes during AV1 design.
2. Isn't optimized for speed, only to be a good reference encoder/decoder
3. Almost all other encoder, the reference encoder isn't fast enough.
4. That's why there are 3º parties implementation of the same codecs dav1d and rav1e
5. Now that the AV1 design is finished, the reference encoder is now optimizing there code for speed.
6. We need to wait until there are hardware acceleration (for decoding 4k/8k UHD) (2, 3 years to be mainstream)
7. New codecs are (always) more complex that the codecs before.
8. New codecs that are releasing now are too much complex for todays CPU, but they are designed to be using mainstream in future CPU 3 years from now.
9. Before AV1 became mainstream, AOM was to begin working in AV2, that will me more complex that AV1, and will be design to CPU released 7 or 8 years from now.
10. Increase the complex is the only way to produce better quality with less space. And that is ok if the hardware continues to improve over time..