Alliance for Open Media codecs

[Clare]

Added AV1 to my comparison: https://wyohknott.github.io/video-formats-comparison/

I had to run it at cpu-used=4 to get a reasonable encode time so it's not representative of the max quality that could be obtained.

You can see that the encode speed is still infinitesimal.

[Shevach]

Originally Posted by foxyshadis

Doesn't seem to have ever been discussed in public. I bet it was a test an engineer inserted and it was just never removed; I wonder if it's ever been used in real life.

Rationales of many AV1 features seem me vague. Woo-Jin Han in LinkedIn forum "AV1 Learning" commented 1/8-pel precision:
" It was proven that high precision mc is only effective for low resolution. Beyond 1080p, even 1/4 pel seems not very effective to justify its complexity. I remember that 1/4 pel shows 30% coding gain for famous Mobile CIF sequence (low res, complex texture, slow motion, aliasing from inadequate down sampler) but average 5-8% over various test sequences. Very high frame rate with non hierarchical structure may change the situation but it seems clear that it is highly sequence dependent tool"

I remember a paper "Motion-Compensating Prediction with Fractional-Pel Accuracy", by B. Girod, 1993 . If we omit a mathematical part of the article and go to the conclusion part, it's written (in my wording): for blocks 16x16 of TV video resolution 1/4-pel motion accuracy appears to be sufficient.

[Shevach]

AV1 enables to omit transmission of skip flags. Indeed, there is the frame-header parameter 'skip_mode_present' and if this parameter equals to 1 then the skip flags are not signalled. The rationale is clear, if we know 'a priory' that encoding of a given frame will not produce skip blocks then it's redundant to transmit skip flags.
Let's look at the situation from another view, what's a penalty in transmission of skip flags provided that all blocks are non-skipped?
Because i am not completely familiar with AV1 entropy coding process i consider AVC/HEVC arithmetic engine instead.
In HEVC/AVC the maximal probability of a symbol is ~0.98 and hence the number of bits produced by encoding a symbol having the maximal probability is -log2(0.98) = ~0.02 bits.
Let's suppose that we know ahead that all MBs will be no-skipped (i.e. skip_flag = 0 for each MB) and consequently the skip_flag syntax element gets maximal probability 0.98. In such case the total number of bits consumed by all skip flags is ~0.02 x Number_Mbs.
For example, HD resolution frame has usually 8100 MBs (16x16 grid) and hence the total size of all skip_flag syntax elements is ~8100 x 0.02 = 162 bits. It's negligible in most cases.
Probably AV1 frame level parameter 'skip_mode_present' (to disable transmission of skip flags) has a minimal impact on coding efficiency, although it increases the decoding complexity (more 'if-else').

[Shevach]

Originally Posted by Clare

Added AV1 to my comparison: https://wyohknott.github.io/video-formats-comparison/

I had to run it at cpu-used=4 to get a reasonable encode time so it's not representative of the max quality that could be obtained.

You can see that the encode speed is still infinitesimal.

What's sense to check codecs with PSNR values 45 dB and greater?
According to HVS research all video with PSNR above 45 dB look perceptual identical to the original.

[Djfe]

Originally Posted by mzso

I still think it's the worst idea ever. Time would have been better spent creating an extraordinary grain filter that leaves useful detail intact. (as much as realistically possible)

Out of curiosity, can the synthesis part (but not the removal.) be disabled (or defeated) to see how it looks without it?

Use the NL-Means filter on Handbrake instead (way too slow for an encoder but beautiful/very good IMO)


Another topic:
Good video to explain people what av1 is, why it was created and by whom etc. (the whole story):
https://youtu.be/lEdqN22vaWs

[wiak]

fresh build today
https://awesome.nwgat.ninja/av1/av1-...nwgat.ninja.7z

[LigH]

AOM 0.1.0-9348-g589bae879

[mzso]

So, a month passed since the (not quite true) news about the bitstream being frozen. Are they closer at least?

[iwod]

Originally Posted by mzso

So, a month passed since the (not quite true) news about the bitstream being frozen. Are they closer at least?

Yes, they are much closer now, as it was last month, and early this year, and late last year......

/s

Honestly, I think it is actually good they delay it. The one thing you don't want is a standard being rushed.

[wiak]

finally newer git builds decode older av1 encoded files, yey for progress

[TD-Linux]

Originally Posted by Shevach

In HEVC/AVC the maximal probability of a symbol is ~0.98 and hence the number of bits produced by encoding a symbol having the maximal probability is -log2(0.98) = ~0.02 bits.
Let's suppose that we know ahead that all MBs will be no-skipped (i.e. skip_flag = 0 for each MB) and consequently the skip_flag syntax element gets maximal probability 0.98. In such case the total number of bits consumed by all skip flags is ~0.02 x Number_Mbs.
For example, HD resolution frame has usually 8100 MBs (16x16 grid) and hence the total size of all skip_flag syntax elements is ~8100 x 0.02 = 162 bits. It's negligible in most cases.
Probably AV1 frame level parameter 'skip_mode_present' (to disable transmission of skip flags) has a minimal impact on coding efficiency, although it increases the decoding complexity (more 'if-else').

For AV1 it's even smaller, 1/65535 of a bit. However you'll need do adapt to that probability, so you'll burn more bits at the beginning of a frame. That said, the skip_mode_present doesn't control the skip flag but rather the skip_mode flag, which itself is a way to signal that you're going to use a "default" predictor. Still, the gains are pretty small, it's more of a speed savings to not have to code this flag if it's unused.

[wiak]

hey TD-Linux fancy meeting you here and in other news mpv windows builds finally has av1 decoding
https://sourceforge.net/projects/mpv...s/files/64bit/

[LigH]

The media-autobuild_suite can help you building your up-to-date mpv as well, based on ffmpeg sources. So if mpv can play it, then ffmpeg may handle it as well? ... Yes:

 DEV.L. av1                  Alliance for Open Media AV1 (decoders: libaom-av1 ) (encoders: libaom-av1 )

[nevcairiel]

Until the bitstream is actually finally frozen, excitement about inclusion in software seems misplaced, since any current binary may not work anymore tomorrow. That should always be kept in mind.

[mzso]

Originally Posted by nevcairiel

Until the bitstream is actually finally frozen, excitement about inclusion in software seems misplaced, since any current binary may not work anymore tomorrow. That should always be kept in mind.

Well, it already can't play a few av1 encodes from a few weeks ago.

[Mierastor]

https://twitter.com/bitmovin/status/996084579952836608

[Pushman]

https://streaminglearningcenter.com/...ix-on-av1.html

Ronca: "We think that initial AV1 computational complexity of 4-10x vs. libvpx would be usable in production. There is a lot of work underway to improve the performance, and we are hopeful that the performance goals will be achieved."

[vidschlub]

Originally Posted by mzso

Well, it already can't play a few av1 encodes from a few weeks ago.

Seriously? That sounds like it's really not ready for prime time.

[nevcairiel]

Originally Posted by vidschlub

Seriously? That sounds like it's really not ready for prime time.

Its quite simply not done yet. We keep repeating that here regularly.
Until its finalized, noone should be using it outside of experimentation/testing.

[vidschlub]

Originally Posted by nevcairiel

Its quite simply not done yet. We keep repeating that here regularly.
Until its finalized, noone should be using it outside of experimentation/testing.

I got the impression from the news announcement that they'd frozen some element of the design, which was a big milestone?

I (wrongly?) assumed, it would just be optomisations and performance from here on out.

I look forward to it dominating, but maybe it's going to be several years?