Alliance for Open Media codecs

[LigH]

No, I could only agree: I would expect multi-threaded processing of frames, possibly in a slices or wavefront partition technology. (AFAIR, AV1 still uses small macroblock-like windows, just more overlapping to neighborhoods...)

[foxyshadis]

I don't think anyone but the developers know what half the options mean or do, though some expected values are in the code. You might try --cpu-used=8, which is supposed to max out the processing power.

Actually don't bother, that argument does nothing, they nerfed it without removing the option. Hm. Maybe pthreads isn't detected correctly? OK, tracing the code, you have to have more than one tile-column to get more than one thread; threading is tile-based only. You'd think default would equal threads, but...?

[Tommy Carrot]

--cpu-used is actually the speed/quality slider, it has nothing to do with threading, they just named it stupidly. The lower it is, the more additional tools and searches are enabled, so 0 is the highest quality, but ridiculously slow, and 8 is the "fastest", but lowest quality.

[colinhunt]

This cmdline

ffmpeg -i moto--x264-8bit-420-1080p2400fps-468frames.mp4 -strict -1 -f yuv4mpegpipe - | aomenc -w 1920 -h 1080 -v --fps=24000/1000 --cpu-used=8 --dev-sf=255 --tile-columns=6 --limit=48 --i420 -t 24 -b 8 --input-bit-depth=8 --end-usage=cbr --target-bitrate=1024 -p 1 --webm --num-tile-groups=32 -o aomout.webm -

resulted in aomenc running 15 threads and cpu load bouncing around between 4 and 20 percent. Encoding 48 frames took approx. 10 minutes.

[LigH]

IMHO, aomenc (and vpxenc the same way) will need a lot of simplification regarding sane defaults and relations between parameters to become user friendly... balancing the presets (and "everything default" equals to the "medium" preset) for x264 and x265 took quite an important part of their development efforts.

[colinhunt]

Source: 1080p24 8bit 4:2:0 468 frames (19.5 seconds)

cmdline: ffmpeg -i moto--x264-8bit-420-1080p2400fps-468frames.mp4 -strict -1 -f yuv4mpegpipe - | aomenc -w 1920 -h 1080 -v --fps=24000/1000 --cpu-used=4 --tile-columns=6 --i420 -t 14 -b 8 --input-bit-depth=8 --end-usage=vbr --target-bitrate=1024 -p 1 --webm -o aomout.webm -

Encoding took 74 minutes, running on 14 threads. Output has a reported (mediainfo) bitrate of 1047 kbps. Oddly enough framerate is reported as 24.025 fps.

[LigH]

Maybe aomenc doesn't count the duration of the very last frame, only the gaps between all of them.

[colinhunt]

Maybe aomenc doesn't count the duration of the very last frame, only the gaps between all of them.
You mean that framerate? That number is from Mediainfo.

[LigH]

Hmm, yes, it looks a bit like "duration / (framecount-1)". So, maybe the opposite way, aomenc counted the duration of the last frame, MediaInfo instead assumes it does not count.

[colinhunt]

I encoded the same 1080p24 8bit 4:2:0 source on aomenc 0.1.0-8449-g6471e8bd7 twice, first with --cpu-used=4 and then with --cpu-used=2. Target bitrate was set for 1024 kbps. Below are the 3SSIM Metric graphs for both encodes.

https://saitti.kuvat.fi/kuvat/VQMetrics/3SSIM-av1cpu2-av1cpu4.png/_medium.jpg

--cpu-used=4 (green) took 4440 seconds to encode, while --cpu-used=2 (red) took 9060 seconds.

[bstrobl]

IETF 101: https://www.youtube.com/watch?v=qS7hfrFWeic

Spec is somewhat "frozen", so only bugfixes left.

[iwod]

IETF 101: https://www.youtube.com/watch?v=qS7hfrFWeic

Spec is somewhat "frozen", so only bugfixes left.

And for anyone that has not been following it, it has been somewhat "Frozen" for nearly 6 months.

As said in the video, there are still crap loads of things going on under the hood. That is not necessarily a bad thing, they are taking the time to properly finish it.

But I have slightly less confident given how they have handle it, I hope they release a preview or beta to the industry before going final.

[nevcairiel]

But I have slightly less confident given how they have handle it, I hope they release a preview or beta to the industry before going final.

The part of the industry that cares is involved in the development already, so whats left?

[bstrobl]

The interesting part about the xvc presentation is that this is basically the current state of JVET/JEM, along with its current bitrate performance that ISO/ITU and co. have managed to achieve.

Obviously there is no way in hell Divideon is getting away with basically a direct rip of JVET, so if xvc gains any commercial ground whatsoever it will simply get sued into oblivion or into updating and making a poor codec. Might as well use VP9/AV1 in that case, especially if no old files become incompatible. The best they can hope for is to basically become a replacement for MPEG LA, but I don't see any lists where they have gained any companies as licensors.

[hajj_3]

The interesting part about the xvc presentation is that this is basically the current state of JVET/JEM, along with its current bitrate performance that ISO/ITU and co. have managed to achieve.

Obviously there is no way in hell Divideon is getting away with basically a direct rip of JVET, so if xvc gains any commercial ground whatsoever it will simply get sued into oblivion or into updating and making a poor codec. Might as well use VP9/AV1 in that case, especially if no old files become incompatible. The best they can hope for is to basically become a replacement for MPEG LA, but I don't see any lists where they have gained any companies as licensors.

They should just try and sell their patents to google/Netflix for a few million dollars and get google/Netflix to donate the patents to IETF to be used in AV2.

P.S mediainfo 18.03 has just been released that can detect AV1 files: http://mediaarea.net/en/MediaInfo

[leonccyiu]

https://www.golem.de/news/videocodec-av1-ist-eingefroren-und-30-prozent-besser-als-vp9-1803-133457.html

According to this German article, the bitstream has been frozen with just a few bugs to work out.

I hope that hardware decoders can come a lot sooner than we expect, and that nvidia and arm have already been working on them.

[hajj_3]

https://www.golem.de/news/videocodec-av1-ist-eingefroren-und-30-prozent-besser-als-vp9-1803-133457.html

According to this German article, the bitstream has been frozen with just a few bugs to work out.

I hope that hardware decoders can come a lot sooner than we expect, and that nvidia and arm have already been working on them.

The article just talks about the conference video that was posted a few days ago. I am more bothered about intel and amd apus getting AV1 hardware decoders quickly than nvidia gpus.

[easyfab]

some tests with foreman clip @250kbit/s on my i7-2600k:

x264 - core 155 r2901 7d0ff22
preset : placebo
real bitrate 263 kb/s size 321 KiB
time : pass 1 : 1s pass 2 : 9s total time : 10 s
metrics :
SSIM All:0.948739 (12.902161)
PSNR average:36.585589
VMAF score = 93.379718

x265 - 2.7+3-9086c8a3e76d:[Windows][GCC 7.3.0][64 bit] 8bit+10bit+12bit
preset : veryslow
real bitrate 254 kb/s size 311 KiB
time : pass 1 : 39s pass 2 : 39s total time : 78 s
metrics :
SSIM All:0.952898 (13.269586)
PSNR average:37.447079
VMAF score = 95.024192

libvpx-vp9 v1.7.0-213-gf4b1eca53
preset : cpu-used 0
real bitrate 238 kb/s size 291 KiB
time : pass 1 : 2s pass 2 : 68s total time : 70 s
metrics :
SSIM All:0.952918 (13.271442)
PSNR average:37.275722
VMAF score = 94.977788

aomenc 0.1.0-8871-g7a3c26460
preset : cpu-used 2
real bitrate 252 kb/s size 307 KiB
time : pass 1 : 2s pass 2 : 1254s total time : 1256 s
metrics :
SSIM All:0.951930 (13.181228)
PSNR average:37.565993
VMAF score = 95.79106


aomenc is real slow for the moment and with cpu-used 2 . I won't try 1080p file for the moment =p

[ChaosKing]

The most important part: Which one of the encodes pleases your eyes the most?

[easyfab]

here you have the result files. I add a av1->x264 (crf 0) file .

https://www.sendspace.com/file/bm5el8

For me av1 is the most "clean"

[bstrobl]

aomenc is real slow for the moment and with cpu-used 2 . I won't try 1080p file for the moment =p

I was expecting a lot slower to be honest :). But as long as the devs can get slightly better quality at roughly the same cpu encode required as VP9 we will have a decent codec on our hands.

[MasterNobody]

How about adding disabling psy-rd for x264 to the mix i.e. `--psy-rd 0` and adding `--aq-mode 2`: https://www.sendspace.com/file/qdj71j
At such bitrates you SHOULD disable --psy-rd in its current form.

[easyfab]

Yes, you're right. I only set preset in previous encode and leave others settings to default. I never encode at so low bitrate, it was only for a small test.

for info, with --psy-rd 0 --aq-mode 2 :

x264 :
SSIM All:0.952115 (13.197976)
PSNR average:37.005003
VMAF score = 95.521538

x265 :
SSIM All:0.956373 (13.602420)
PSNR average:38.090090
VMAF score = 96.459293

[JohnLai]

Nobody post the news?

https://twitter.com/mattication/status/976774873316982784

https://aomediacodec.github.io/av1-spec/

[nevcairiel]

Some random unknown person tweeting a claim that its finished doesn't seem overly convincing. The spec still has a huge draft warning on top, afterall, and the github repo behind it is still changing daily.

[sneaker_ger]

Are they still using "Golden Frames"? Shouldn't the bframe patents have expired by now?

[bstrobl]

Some random unknown person tweeting a claim that its finished doesn't seem overly convincing. The spec still has a huge draft warning on top, afterall, and the github repo behind it is still changing daily.

There are currently only 3 bugs pertaining to the bitstream itself that need to be finished: https://bugs.chromium.org/p/aomedia/issues/list?can=2&q=Hotlist%3DAV1-Normative+&colspec=ID+Type+Status+Priority+Milestone+Owner+Summary&cells=ids

So it should be close to being done.

[hajj_3]

https://bitmovin.com/av1-multi-codec-dash-dataset/
https://bitmovin.com/cool-new-video-tools-five-encoding-advancements-coming-av1/

[mzso]

https://bitmovin.com/av1-multi-codec-dash-dataset/
https://bitmovin.com/cool-new-video-tools-five-encoding-advancements-coming-av1/

The goal is to de-noise the initial content before encoding it and then re-adding the noise or grain effect before output during the decoding process. This way, the unnecessary information would not have to be transmitted at all and the overall load of data could be reduced substantially.

It would be even better if the second stupid step would be skipped.
I hope at least that decoders will have an option to disable artificial noise generation.

[LigH]

Without adding it back, the result may look strangely artifical ("plastic") and may not cover compression artifacts well, I guess ... so I'm curious to see that, whether confirming my guess or not.

[nevcairiel]

Grain/Noise-synthesis is not a new concept, H.264 supported it as well, but it never saw any use. This may be more advanced, but we'll see.

In any case, if you want to permanently denoise/degrain a movie, then just do so in pre-processing, but if its a codec feature then it should always be applied in decoding and the image reconstructed fully and properly. My decoders will certainly not offer any options to output a degraded image.

[mzso]

Without adding it back, the result may look strangely artifical ("plastic") and may not cover compression artifacts well, I guess ... so I'm curious to see that, whether confirming my guess or not.

I think, only if the grain filter sucks and removes a lot of actual detail/pattern.

[nevcairiel]

I think, only if the grain filter sucks and removes a lot of actual detail/pattern.

Such a grain filter is designed for coding efficiency, with the design in mind that the grain will be added back. It does not have to be designed to "look good" without the grain. So chances are that it won't.

[sneaker_ger]

Grain/Noise-synthesis is not a new concept, H.264 supported it as well, but it never saw any use. This may be more advanced, but we'll see.
But optional, IIRC. I think basically no decoder implemented it.

Will it be mandatory for AV1?

[mzso]

Such a grain filter is designed for coding efficiency, with the design in mind that the grain will be added back. It does not have to be designed to "look good" without the grain. So chances are that it won't.

Oh, well. As you said, we'll see. :)

[foxyshadis]

Are they still using "Golden Frames"? Shouldn't the bframe patents have expired by now?

Golden Frames are a technically elegant solution in their current form; there's no real reason to switch back to B-frames. There's a bit more bookkeeping overhead, which is largely squeezed out in the entropy coding, but the flip side is greater flexibility if the encoder chooses to use it. (VP9's implementation generally doesn't stray far from the classic P and B types, but AV1 supposedly uses them to greater effect by shuffling blocks around in more interesting ways.)

[foxyshadis]

But optional, IIRC. I think basically no decoder implemented it.

Will it be mandatory for AV1?

Absolutely, just like the in-loop filter.

[LigH]

New upload: AOM v0.1.0-8892-g10b745615

[mzso]

I wonder if aom will remain the only encoder/decoder, or whether third parties will develop something such as x264/x265 projects or maybe the ffmpeg people.

(Didn't there used to be an ffvp8 encoder (http://blog.webmproject.org/2010/08/ffmpeg-vp8-decoder-implementation.html)? I don't see it listed in ffmpeg as a decoder/codec.)

[LigH]

Of course, there will be several "Next Generation Video Codec" projects; e.g. there is a lively discussion about xvc (https://forum.doom9.org/showthread.php?t=175110) in this board. ... BTW, where is schweinsz (https://forum.doom9.org/showthread.php?t=168327)?

On2 VP8 / Google VP9 can be used in ffmpeg, no more need to develop an alternative decoder, I guess... a non-free "everything goes" ffmpeg build by the media-autobuild_suite contains:

DEV.L. vp8 On2 VP8 (decoders: vp8 libvpx vp8_cuvid vp8_qsv ) (encoders: libvpx )
DEV.L. vp9 Google VP9 (decoders: vp9 libvpx-vp9 vp9_cuvid ) (encoders: libvpx-vp9 )

I am quite confident that an ffmpeg with a more restricted license, which is allowed to be distributed (like zeranoe's selection (https://ffmpeg.zeranoe.com/builds/)), will contain them too.

But as long as the AV1 format is not "frozen", ffmpeg will at most "know about it" (maybe detect its presence in some containers with matching content type flags?); as codec it is not yet implemented.

..V.L. av1 Alliance for Open Media AV1

Quoted output is part of ffmpeg -codecs

[nevcairiel]

Once av1 takes off, I would expect someone to develop a decoder for ffmpeg eventually. Encoders, probably not. Thats more suited for stand-alone projects from the sheer complexity of it.

[sneaker_ger]

Of course, there will be several "Next Generation Video Codec" projects; e.g. there is a lively discussion about xvc (https://forum.doom9.org/showthread.php?t=175110) in this board. ... [i]BTW, where is schweinsz (https://forum.doom9.org/showthread.php?t=168327)?
I think mzso means other implementations of the AV1 specs. For example ffmpeg has two VP9 software decoders (as your quote from the help shows), the one coming from Google ("libvpx-vp9") and FFvp9 (https://blogs.gnome.org/rbultje/2014/02/22/the-worlds-fastest-vp9-decoder-ffvp9/) ("vp9") developed in spite of already having the free Google one.

[LigH]

If ffmpeg developers disagree with some opinions of the original team about e.g. programming styles, I would not be surprised if they may be going to show how it can be made better; wasn't that a reason to develop VPx codecs in parallel to Google? I do not remember everything in detail, but I believe efficiency was one of the focus points.

[mzso]

I think mzso means other implementations of the AV1 specs. For example ffmpeg has two VP9 software decoders (as your quote from the help shows), the one coming from Google ("libvpx-vp9") and FFvp9 (https://blogs.gnome.org/rbultje/2014/02/22/the-worlds-fastest-vp9-decoder-ffvp9/) ("vp9") developed in spite of already having the free Google one.

I don't see ffvp9 either in ffmpeg (zeranoe), which is strange if it's an ffmpeg internal decoder, as suggested the "ff" part.

[sneaker_ger]

Like I quoted:
-c:v "vp9" is ffvp9
-c:v "libvpx-vp9" is the one from Google

[nevcairiel]

They are not called "ffvp9" internally, its just "vp9", which is listed in the quoted output above.

Anyway distinct decoder implementations have several advantages. Often it helps to find bugs in the original decoder, and historically the ffmpeg decoders have also been faster - and they serve as a platform for hardware acceleration, which is not possible with an external decoder like using libaom.

[mzso]

@sneaker_ger @nevcairiel
Ah, okay. Thanks for clearing that up. It was also confusing that it's named google VP9:
VFS..D vp9 Google VP9
V....D libvpx-vp9 libvpx VP9 (codec vp9)

Once av1 takes off, I would expect someone to develop a decoder for ffmpeg eventually. Encoders, probably not. Thats more suited for stand-alone projects from the sheer complexity of it.

Yeah, a completely software encoder doesn't feel too likely to me. I guess if someone really wants a feature can just add it to aomenc, unless they're just morbidly resistant to external input. Maybe fork it at most.

[LigH]

it's named google VP9

because Google developed the specifications (theory) further from the base of the VP8 specifications originally developed by On2. But there can be different implementations (practice), not only from Google, but also from different authors, still based on the same specifications, but with different code. The listing is indeed not really unambiguous.

[easyfab]

aomedia.org new site :)

Coming Soon to a Screen Near You

[hajj_3]

aomedia.org new site :)

Coming Soon to a Screen Near You

Site looks nice :)