Alliance for Open Media codecs

[dapperdan]

Did the Netflix rep say they were supporting work on the Eve encoder and seeing an extra 5% improvement? That's pretty cool.

[easyfab]

http://www.streamingmediaglobal.com/Articles/ReadArticle.aspx?ArticleID=118062

OT @dappedan

"he mentioned that they weren't using the stock open-source VP9 encoder available from Google. Rather, they were encoding with technology from a company called Two Orioles, which was founded by Ronald Bultje, a lead VP9 developer. Ronca mentioned that in particular, Netflix had found that the open-source VP9's two-pass rate control mechanism was suboptimal, and that Bultje's encoder is currently about 8% more efficient than Google's."

/OT

"Google's Frost claimed that AV1 was currently 30-35% more efficient than VP9"

Is correct that's nice .

[dapperdan]

That does introduce ambiguity into their comments about e.g. AV1 is 20% better than VP9, do they mean libvpx or eve encoded VP9? Since that could mean a further 8% difference.

[Gravitator]

I do not get normal (smeared squares) AV1 playback through tmodLAV (http://tmod.nmm-hd.org/LAVFilters/).
Samples > https://www.elecard.com/videos

[mzso]

I do not get normal (smeared squares) AV1 playback through tmodLAV (http://tmod.nmm-hd.org/LAVFilters/).
Samples > https://www.elecard.com/videos

Which other options are there to play AV1 videos?

[sneaker_ger]

You are dealing with experimental software and the bitstream hasn't been frozen yet. A sample created with yesterday's encoder might not work with today's decoder. Such things are expected. If you think you found a "real" bug in either encoder or decoder report it to the developers.

[Gravitator]

Which other options are there to play AV1 videos?
Elecard MPEG Player (only my processor can not cope - it slows down).

[mzso]

You are dealing with experimental software and the bitstream hasn't been frozen yet. A sample created with yesterday's encoder might not work with today's decoder. Such things are expected. If you think you found a "real" bug in either encoder or decoder report it to the developers.

Do you know of recent samples one can download?

[sneaker_ger]

I don't.

[wiak]

here is the thing "its not finished, so a newer or older decoder will not work, it has to be exact"
there is one way to do it, its to encode a file and use ./aomdec file.webm| mpv -

[stax76]

How does 2 pass work?

D:\Projekte\VS\VB\StaxRip\bin\Apps\ffmpeg\ffmpeg.exe -i D:\Temp\staxrip\Eli_temp\Eli.avs -f yuv4mpegpipe - | D:\Projekte\VS\VB\StaxRip\bin\Apps\aomenc\aomenc.exe - --passes=2 --pass=1 --target-bitrate=1167 -o D:\Temp\staxrip\Eli_temp\Eli_out.webm

av_interleaved_write_frame(): Broken pipe
Error writing trailer of pipe:: Broken pipe
frame= 1 fps=0.0 q=-0.0 Lsize= 191kB time=00:00:00.03 bitrate=46971.0kbits/s speed=0.0618x
video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 39397.984375%
Conversion failed!

[wiak]

How does 2 pass work?

D:\Projekte\VS\VB\StaxRip\bin\Apps\ffmpeg\ffmpeg.exe -i D:\Temp\staxrip\Eli_temp\Eli.avs -f yuv4mpegpipe - | D:\Projekte\VS\VB\StaxRip\bin\Apps\aomenc\aomenc.exe - --passes=2 --pass=1 --target-bitrate=1167 -o D:\Temp\staxrip\Eli_temp\Eli_out.webm

av_interleaved_write_frame(): Broken pipe
Error writing trailer of pipe:: Broken pipe
frame= 1 fps=0.0 q=-0.0 Lsize= 191kB time=00:00:00.03 bitrate=46971.0kbits/s speed=0.0618x
video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 39397.984375%
Conversion failed!

1. you cant pipe
2. its default
3. so far i know

[stax76]

Is there a avs/vs reader then?

[sneaker_ger]

I vaguely remember you having the same problem with the VP9 encoder. With auto-2pass piping doesn't work because it cannot rewind the pipe. But manual 2pass should be possible or is that feature not available in the AV1 encoder? Or does it really not support pipe input at all?

[stax76]

staxrip uses ffmpeg for VP9 but I don't remember how it works. I've tried with avs input:

C:\WINDOWS\system32>D:\Projekte\VS\VB\StaxRip\bin\Apps\aomenc\aomenc.exe D:\Temp\staxrip\Eli_temp\Eli.avs --target-bitrate=1167 -o D:\Temp\staxrip\Eli_temp\Eli_out.webm
Fatal: Specify stream dimensions with --width (-w) and --height (-h)

edit:

C:\WINDOWS\system32>D:\Projekte\VS\VB\StaxRip\bin\Apps\aomenc\aomenc.exe D:\Temp\staxrip\Eli_temp\Eli.avs --target-bitrate=1167 --width=1280 --height=720 -o D:\Temp\staxrip\Eli_temp\Eli_out.webm
Pass 1/2 frame 0/0 0B 0b/f 0b/s 0 us (0.00 fps)
Failed to initialize encoder: Invalid parameter
rc_twopass_stats_in requires at least two packets.

[stax76]

Is there a place to get support from the developers?

[wiak]

Is there a place to get support from the developers?

#aomedia @ irc.freenode.net probobly your best bet, or there is http://aomedia.org/contact/

btw aoem isnt even done yet sooo

[sneaker_ger]

Try with y4m input via pipe:
aomenc --pass=1 --passes=2 --fpf="statsfile.txt" -o "output" -
aomenc --pass=2 --passes=2 --fpf="statsfile.txt" -o "output" -

[stax76]

Thanks, got it working now as it seems.

https://postimg.org/image/vbjihxjml/

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Encoding video using aomenc May 2017
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

@echo off
D:\Projekte\VS\VB\StaxRip\bin\Apps\ffmpeg\ffmpeg.exe -i D:\Temp\staxrip\Eli_temp\Eli.avs -f yuv4mpegpipe - | D:\Projekte\VS\VB\StaxRip\bin\Apps\aomenc\aomenc.exe - --passes=2 --pass=1 --target-bitrate=1167 --fpf=D:\Temp\staxrip\Eli_temp\Eli.txt -o D:\Temp\staxrip\Eli_temp\Eli_out.webm

cmd.exe /C call D:\Temp\staxrip\Eli_temp\Eli_encode.bat

ffmpeg version 3.3.1 Copyright (c) 2000-2017 the FFmpeg developers
built with gcc 6.3.0 (GCC)

Input #0, avisynth, from 'D:\Temp\staxrip\Eli_temp\Eli.avs':
Duration: 00:00:43.41, start: 0.000000, bitrate: 0 kb/s
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 480x272, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc
Stream mapping:
Stream #0:0 -> #0:0 (rawvideo (native) -> wrapped_avframe (native))
Press [q] to stop, [?] for help
Output #0, yuv4mpegpipe, to 'pipe:':
Metadata:
encoder : Lavf57.71.100
Stream #0:0: Video: wrapped_avframe, yuv420p, 480x272, q=2-31, 200 kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc
Metadata:
encoder : Lavc57.89.100 wrapped_avframe
Pass 1/2 frame 1/0 0B 0 us 0.00 fpm [ETA unknown] [K
Pass 1/2 frame 2/1 176B 2963 us 674.99 fps [ETA unknown] [K
Pass 1/2 frame 3/2 352B 5649 us 531.07 fps [ETA unknown] [K
Pass 1/2 frame 4/3 528B 8217 us 486.80 fps [ETA unknown] [K
Pass 1/2 frame 5/4 704B 10686 us 467.90 fps [ETA unknown] [K
Pass 1/2 frame 6/5 880B 12733 us 471.22 fps [ETA unknown] [K
Pass 1/2 frame 7/6 1056B 14736 us 475.03 fps [ETA unknown] [K
Pass 1/2 frame 8/7 1232B 16749 us 477.64 fps [ETA unknown] [K
Pass 1/2 frame 9/8 1408B 18797 us 478.80 fps [ETA unknown] [K

Start: 19:32:48
End: 19:32:53
Duration: 00:00:04

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Encoding video second pass using aomenc May 2017
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

@echo off
D:\Projekte\VS\VB\StaxRip\bin\Apps\ffmpeg\ffmpeg.exe -i D:\Temp\staxrip\Eli_temp\Eli.avs -f yuv4mpegpipe - | D:\Projekte\VS\VB\StaxRip\bin\Apps\aomenc\aomenc.exe - --passes=2 --pass=2 --target-bitrate=1167 --fpf=D:\Temp\staxrip\Eli_temp\Eli.txt -o D:\Temp\staxrip\Eli_temp\Eli_out.webm

cmd.exe /C call D:\Temp\staxrip\Eli_temp\Eli_encode.bat

ffmpeg version 3.3.1 Copyright (c) 2000-2017 the FFmpeg developers
built with gcc 6.3.0 (GCC)

Input #0, avisynth, from 'D:\Temp\staxrip\Eli_temp\Eli.avs':
Duration: 00:00:43.41, start: 0.000000, bitrate: 0 kb/s
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 480x272, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc
Stream mapping:
Stream #0:0 -> #0:0 (rawvideo (native) -> wrapped_avframe (native))
Press [q] to stop, [?] for help
Output #0, yuv4mpegpipe, to 'pipe:':
Metadata:
encoder : Lavf57.71.100
Stream #0:0: Video: wrapped_avframe, yuv420p, 480x272, q=2-31, 200 kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc
Metadata:
encoder : Lavc57.89.100 wrapped_avframe
frame= 27 fps=1.4 q=-0.0 size= 5164kB time=00:00:00.90 bitrate=46956.7kbits/s speed=0.0458x
frame= 28 fps=1.3 q=-0.0 size= 5355kB time=00:00:00.93 bitrate=46956.6kbits/s speed=0.0429x
frame= 30 fps=1.3 q=-0.0 size= 5738kB time=00:00:01.00 bitrate=46956.6kbits/s speed=0.0433x
frame= 31 fps=0.9 q=-0.0 size= 5929kB time=00:00:01.03 bitrate=46956.6kbits/s speed=0.029x
frame= 32 fps=0.8 q=-0.0 size= 6120kB time=00:00:01.06 bitrate=46956.6kbits/s speed=0.0281x
frame= 34 fps=0.8 q=-0.0 size= 6503kB time=00:00:01.13 bitrate=46956.5kbits/s speed=0.0274x
frame= 35 fps=0.8 q=-0.0 size= 6694kB time=00:00:01.16 bitrate=46956.5kbits/s speed=0.0257x
frame= 36 fps=0.7 q=-0.0 size= 6885kB time=00:00:01.20 bitrate=46956.5kbits/s speed=0.0246x
frame= 38 fps=0.7 q=-0.0 size= 7268kB time=00:00:01.26 bitrate=46956.5kbits/s speed=0.0241x
frame= 39 fps=0.4 q=-0.0 size= 7459kB time=00:00:01.30 bitrate=46956.5kbits/s speed=0.013x
frame= 40 fps=0.3 q=-0.0 size= 7650kB time=00:00:01.33 bitrate=46956.5kbits/s speed=0.0107x
frame= 42 fps=0.3 q=-0.0 size= 8033kB time=00:00:01.40 bitrate=46956.4kbits/s speed=0.0103x

[mzso]

Too bad Montgomery stopped with the Dalaa blogs. Now there's no info (that mere mortals can comprehend) about what stuff they're experimenting with.

[stax76]

There's a first staxrip test build with AV1 support, feedback for tab names and labels would be a really helpful.

https://postimg.org/image/hjhoy7qar

https://github.com/stax76/staxrip/blob/master/Encoding/AV1Encoder.vb#L144

https://forum.doom9.org/showthread.php?p=1808526#post1808526

[nevcairiel]

I hope you have a huge warning somewhere that people should really not encode videos in AV1 if they care to be playable in the future? :) AV1 is not done yet, and files encoded with a certain encoder version will not be compatible with future decoders.

[stax76]

I guess you are right, I've changed the title bar to: Under construction, AV1 isn't finished yet

[TD-Linux]

I found this comparison betwen beta of AV1, HEVC and AVC by the Fraunhofer Heinrich Hertz Institute:

http://iphome.hhi.de/marpe/download/Preprint-Performance-Comparison-AV1-HEVC-AVC-PCS2016.pdf

The result is somewat surprising but not much if we think who did it and the development status of AV1, after reading it I also find it of poor quality and with various possibilities for errors plus it's potentially in conflict with other studies.

This paper is old now, but I didn't see this documented anywhere else, so:

This paper made the same error as their previous VP9 comparison paper. They allow x265 to do fixed quantizer modulation, but lock AV1 to a single quantizer per frame. x265's --qp option still varies per-frame qp's via ipFactor and pbFactor.

Even if they had set both x265 factors to 1.0, there would still be the problem that H.265 itself maps the QP value to different "real" quantizers based on keyframe or not, as part of the bitstream. So you'd actually have to null that out with a "backwards" ipFactor, or adjust AV1 to have a similar boost.

[blurred]

Hot thread about Google ANS patent for AV1:
https://www.reddit.com/r/programming/comments/6h08z5/google_is_currently_trying_to_patent_video/?sort=confidence

[ls1dreams]

Anyone have a prediction on which intel series chip/igpu this will make it into?

- coffee lake
- cannonlake
- later?

Coffee Lake seems unlikely since timing is about the same time as they plan to freeze the AV1 bitstream, unless the alliance has been working VERY closely with intel. Cannonlake even shortly after seems like it's rather tight.

[soresu]

Seems likeliest that the first accelerated implementations will be GPGPU or DSP based prior to ASIC for at least a year after bitstream is frozen later this year (assuming they manage to freeze at all this year).

[soresu]

A more interesting question is whether AV1 will be more amenable to parallel implementations than VP9, or even HEVC - which was a key goal originally for Daala, given the slow progress in CPU single thread performance, GPGPU or some other massively parallel accelerator represents a far more efficient target, and OTOY's ORBX codec shows that it can be done, strange that they are completely absent from the Alliance to be honest.

[Beelzebubu]

A more interesting question is whether AV1 will be more amenable to parallel implementations than VP9, or even HEVC - which was a key goal originally for Daala, given the slow progress in CPU single thread performance, GPGPU or some other massively parallel accelerator represents a far more efficient target, and OTOY's ORBX codec shows that it can be done, strange that they are completely absent from the Alliance to be honest.

Why do you believe VP9 was not parallelizable? I think FFmpeg's decoder showed that parallelism is not an issue. The fact that Google's decoder didn't use parallelism has nothing to do with the format.

[soresu]

Ah, when talking about parallelism, I meant the encoder rather than the decoder, which is usually more compute intensive and seems to increase in complexity sometimes an order of magnitude or more per generation, while the decoder seems to be only a modest increase albeit still enough to hurt in the current climate of slow single thread improvement.

It seems that the likes of Netflix and Google get around parallelisation limits (atleast limits that dont impact compression efficiency) of H264, HEVC and VP9 by employing chunked encoding over the gamut of a server farm/datacenter, but this is still limited to CPU compute.

It would be interesting to see if we could at least see GPGPU employed efficiently for chunked encoding, if not for full length videos.

[Beelzebubu]

Without wanting to get too much into detail, I would claim that the issue here is in the implementation, not the format. There are alternative VP9 encoder implementations that are far less limited in their parallelism.

[nevcairiel]

It would be interesting to see if we could at least see GPGPU employed efficiently for chunked encoding, if not for full length videos.

GPGPU for encoding has never really been any successfull. You would probably have to design a codec with that as a key basic design for it to work decently, and it would probably have drawbacks anywhere else - ie. not be very general purpose.
The thing about GPGPU is that it only works well if a simple task can be parallized a whole lot. Encoding thousands of chunks at the same time would not be very simple (in fact a single chunk would be rather complex), and likely not work very well.

I do think however that the codecs we currently have do scale well enough to keep multi-core CPUs busy just fine, encoder implementations not withstanding.

[Nintendo Maniac 64]

I would imagine that the first GPUs implementing hardware AV1 decoding would be the middle of 2018 at the earliest.

CPU-wise, that would line up well with Zen2 APUs (H2 2018 - H1 2019) but if you insist on Intel you'd have to wait for Icelake in 2019.

[Przemek_Sperling]

The thing about GPGPU is that it only works well if a simple task can be parallized a whole lot.

I can't believe it :devil:

;-)

[Phanton_13]

GPGPU for encoding has never really been any successfull. You would probably have to design a codec with that as a key basic design for it to work decently, and it would probably have drawbacks anywhere else - ie. not be very general purpose.
The thing about GPGPU is that it only works well if a simple task can be parallized a whole lot. Encoding thousands of chunks at the same time would not be very simple (in fact a single chunk would be rather complex), and likely not work very well..
Actually the bigest problem is that you have to throw to the sink the knowledge and commom sense in algorithms that you learned doing commom programing. I learned this the hard way when I helped in the parallezitaion of a problem, we made it faster doing it slower... basically our solution was around ten times slower than the clasical one runing only one thread, but the clasical one was mostly limited to 12 threads and our was able to scale to more than 1000 threads and that resulted in it being around 80 times faster that the clasical solution in the machine where it was run.

Sorry for my english, I'n not a native speaker.

[easyfab]

And 2 new members : Hulu and Argon Design.

https://www.hulu.com/press/product_update/hulu-joins-the-alliance-for-open-media/
http://www.argondesign.com/news/2017/jun/28/argon-joins-aom/

Now I hope the bitstream freeze will come in 2017.

[wiak]

And 2 new members : Hulu and Argon Design.

https://www.hulu.com/press/product_update/hulu-joins-the-alliance-for-open-media/
http://www.argondesign.com/news/2017/jun/28/argon-joins-aom/

Now I hope the bitstream freeze will come in 2017.
VideoLAN also joined https://www.videolan.org/press/aomedia.html

[stax76]

And I hope the command line interface design and documentation improves to the same excellence as x264 and x265.

[wiak]

And I hope the command line interface design and documentation improves to the same excellence as x264 and x265.
and multi-threading :sly:

[stax76]

And native AviSynth and VapourSynth support. :)

[easyfab]

And after bitstream freeze I dream of others encoders like ffav1 ( ffmpeg team ) or xav1 ( like x264 ) with multi-threading and a lot of asm optimizations to enable better competition .

[bstrobl]

I am hoping that they will not rush out a bitstream with flaws in it. If it takes a bit longer than 2017 I guess that would be fine, since these codecs have much longer lifespans than companies like Google would like (remember the whole "every year a new codec" thing).

MP3 is still being used and progress in codecs is slowing gradually. Only so much Information can be crammed into a small file size. Getting this codec right the first time would be great.

[leandro]

I really hope they freeze bitstream this year too.

[nakTT]

I am hoping that they will not rush out a bitstream with flaws in it. If it takes a bit longer than 2017 I guess that would be fine, since these codecs have much longer lifespans than companies like Google would like (remember the whole "every year a new codec" thing).

MP3 is still being used and progress in codecs is slowing gradually. Only so much Information can be crammed into a small file size. Getting this codec right the first time would be great.
Exactly. While i do hoping for it to be this year but in the interest of getting it right the first time, I would rather see them taking time to sort thing out for the better.

[mzso]

If it takes a bit longer than 2017 I guess that would be fine, since these codecs have much longer lifespans than companies like Google would like (remember the whole "every year a new codec" thing).

Another reason I don't understand why they're still handicapping it with historic baggage like chroma subsampling and YUV. (At least interlacing seems to be gone for good.)
(Are they still doing the limited range nonsense too?)

[Quikee]

Another reason I don't understand why they're still handicapping it with historic baggage like chroma subsampling and YUV. (At least interlacing seems to be gone for good.)
(Are they still doing the limited range nonsense too?)

What's the alternative? Chroma subsampling is a good way to shave of quite a bit of image data without most people noticing it or caring about it.

[mzso]

What's the alternative? Chroma subsampling is a good way to shave of quite a bit of image data without most people noticing it or caring about it.

It's not a good way, it's a very bad, primitive way.

The alternative: no subsampling. Let the encoder reduce color information in a more evolved way. An immediately obvious possibility is that you could change how color/luminosity is stored adaptively.

eg: when there's only the sky on the picture why dump half the color information for the blue range of the spectrum even before it reaches the encoder? Why "keep" anything for the red range? (The only color is blue, or white/grey aka no-color)

[nevcairiel]

Can we not repeat this discussion every couple months? You can't force content producers on a technical level, they'll just not use the codec then. Convince them that they want to use 4:4:4 or RGB, not that they have to.

Additionally, a lot of content already exists that is already subsampled. Being forced to upsample that before encoding isn't going to do anyone any good, and as such a codec that can't encode a vast amount of existing content is not going to see adoption. Its as simple as that.

[Clare]

Hey guys,

I've updated my image comparison website, now you can compare AV1 from oct 2016 to AV1 from now.

You can see the changes in metrics here: http://wyohknott.github.io/image-formats-comparison/comparison.html

[wiak]

Hey guys,

I've updated my image comparison website, now you can compare AV1 from oct 2016 to AV1 from now.

You can see the changes in metrics here: http://wyohknott.github.io/image-formats-comparison/comparison.html
can you add VP9 and HEVC in that too?