Alliance for Open Media codecs

[Blue_MiSfit]

Originally Posted by olduser217

Just curious whether the bit distribution of AV1 is similar as VP9 too, i.e. the non-display inter frames are being allocated with much higher bits (more than 10 times) compared to the displayed inter frames.
This seems like not mentioned in the AV1 specification.

Wouldn't this behavior be a result of encoder implementation, and not have anything to do with the bitstream specs?

[benwaggoner]

Originally Posted by Blue_MiSfit

Wouldn't this behavior be a result of encoder implementation, and not have anything to do with the bitstream specs?

Yeah, that would be my assumption as well.

Using WAY more bits on non-visible Intra frames than intra frames seems pathological. Unless there’s some reason why the displayed frame is just one big skip block of the golden frame or something. It would be interesting to look at the per-frame allocation with/without non-display frames on. I’d guess that having only visible intra frames would result in having a lot larger intra frames.

Is there any good data on the efficiency improvements from golden & non-visible intra frames?


Sent from my iPad using Tapatalk

[olduser217]

Originally Posted by Blue_MiSfit

Wouldn't this behavior be a result of encoder implementation, and not have anything to do with the bitstream specs?

Yes, this definitely about the encoder implementation rather than specification/standard.
However, since both Youtube and Neflix VP9 bitstreams show similar bit distribution pattern, just wondering whether the same will happen to AV1.

[olduser217]

Originally Posted by benwaggoner

Yeah, that would be my assumption as well.

Using WAY more bits on non-visible Intra frames than intra frames seems pathological. Unless thereÂ’s some reason why the displayed frame is just one big skip block of the golden frame or something. It would be interesting to look at the per-frame allocation with/without non-display frames on. IÂ’d guess that having only visible intra frames would result in having a lot larger intra frames.

Is there any good data on the efficiency improvements from golden & non-visible intra frames?


Sent from my iPad using Tapatalk

The non-display frames (invisible frames) are actually inter frames. The bit allocated for each of these non-display inter frames are still less than the Key frame (but much higher than other displayed inter frame).

Take the example decoding order of VP9 bitstream below:
I0 NP0 P0 P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 P12

I0 is the Key frame, NP0 is the non-display inter frame and Pn are the displayed inter frames.

The display order is:
I0 P0 P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 P12

NP0 is actually encoded using the same input frame to encode P12.
In the sequence above, I0 is always used as the GOLDEN frame, NP0 always the ALTREF frame and the last decoded frame as the LAST FRAME.

This NP0 is actually encoded mainly for backward prediction in bi-directional prediction.

[marcomsousa]

AV1 will be disable in Chome 69.

AV1 is not ready. Disable it on the M69 branch.

https://chromium.googlesource.com/ch...96192818654436

[v0lt]

Originally Posted by olduser217

NP0 is actually encoded using the same input frame to encode P12.
In the sequence above, I0 is always used as the GOLDEN frame, NP0 always the ALTREF frame and the last decoded frame as the LAST FRAME.

This NP0 is actually encoded mainly for backward prediction in bi-directional prediction.

It's wrong to call the frame. This is additional information for the GOP sequence. It could simply be added to the first frame and you would not have to invent the unseen frames.

[IgorC]

rav1e improves quite fast
https://twitter.com/fg118942/status/1033280738869706752

[mzso]

Originally Posted by IgorC

rav1e improves quite fast
https://twitter.com/fg118942/status/1033280738869706752

https://pbs.twimg.com/media/DlbzTq4U0AEWcuB.png

So now it has motion compensation. It's still a fair bit worse than x264, what other basic features might be missing?


I suppose you don't happen to have a graph on speed improvement?

[Rumbah]

Originally Posted by mzso

It's still a fair worse than x264, what other basic features might be missing?

I think it's still intra only.

[fg118942]

I use google translation.

I created not only the graph but also uploaded the encoded image to imgur.
https://imgur.com/a/ifs2bn3

Also rav1e is still late, it takes over an hour to convert 1080p 375 frames of movies.

[Tommy Carrot]

Originally Posted by Rumbah

I think it's still intra only.

Nah, it definitely has inter frames, and some basic motion compensation. It doesnt have deblocking filter, b-frames and many other features yet, and the quality is not very good, but it has improved a lot in the last few days. The encoding speed is getting slower though, in the slower speed settings it's getting close to aomenc level, and they still need to keep adding a lot of new features to the encoder.

[olduser217]

Originally Posted by v0lt

It's wrong to call the frame. This is additional information for the GOP sequence. It could simply be added to the first frame and you would not have to invent the unseen frames.

Hi, what do you mean by "It's wrong to call the frame"?
This is NOT just simply an "additional information for the GOP sequence". The data of the non-display frame is there and the decoder has to spend time to decode that like a normal frame, except it doesn't display it.

And what do you mean by "It could simply be added to the first frame"?
I didn't invent the frame, it was encoded by VP9 encoder of libvpx.

[v0lt]

Originally Posted by olduser217

This is NOT just simply an "additional information for the GOP sequence". The data of the non-display frame is there and the decoder has to spend time to decode that like a normal frame, except it doesn't display it.

This is additional information for the GOP sequence that needs to be decoded. Calling it frames is wrong.

[v0lt]

I have a problem with the rav1e encoder. The resulting IVF files play poorly in ffplay and mpv. I can not convert these frames to MKV using ffmpeg or mkvtoolnix.
My IVF AV1 files.

[Mosu]

The mapping for AV1 in Matroska hasn't been finalized yet. Therefore you cannot convert IVF to Matroska, and even if you could, the resulting files would be invalid.

[LigH]

Originally Posted by olduser217

Hi, what do you mean by "It's wrong to call the frame"?

I believe v0lt dropped an 'm': "It's wrong to call them frame".

And as we are just discussing little details:

Besides WebM and IVF (funny to discover it is based on a legacy container known as "Indeo Video Format"), aomenc also can create "OBU" (Open Bitstream Units); am I right that this format is more similar to the one of raw AVC?

[olduser217]

Originally Posted by v0lt

This is additional information for the GOP sequence that needs to be decoded. Calling it frames is wrong.

I do not agree about this.
Even though these frames are not going to be displayed, they definitely need to be decoded as a frame, stored and take up memory space of a frame in the decoded picture buffer as a reference frame for future frame decoding.

Even the requirement of Youtube mentions that the decoding frame rate can be higher than displaying frame rate, which implying that these "additional information" are exact frame(s).

Anyway, there is no point arguing about this, if your implementation can ignore the performance required to encode/decode these "additional information".

[nevcairiel]

Originally Posted by LigH

Besides WebM and IVF (funny to discover it is based on a legacy container known as "Indeo Video Format"), aomenc also can create "OBU" (Open Bitstream Units); am I right that this format is more similar to the one of raw AVC?

OBU is the AV1 name for "NALU" (ie. the generic name for every high level element of a bitstream), it does not indicate a specific storage format. You cannot really store AV1 without a container, much like VP9. Thats why IVF exists, an extremely no-frills container serving as a "raw" format, since pure "raw" is not something you should do.

[Mosu]

Originally Posted by LigH

Besides WebM and IVF (funny to discover it is based on a legacy container known as "Indeo Video Format"), aomenc also can create…

Just to make this very clear: the WebM aomenc produces is not valid. As I said before, the mapping for AV1 in Matroska & WebM hasn't been finalized yet, and what aomenc produces is definitely not going to be what the specs will say how it should be.

[Aleksoid1978]

Hello all. Can somebody build static .lib(for me need only AV1 decoder) x86/x64 version.
I want try add to MPC-BE/ffmpeg library.