Alliance for Open Media codecs [Archive] - Page 17

iwod

30th July 2018, 13:51

Off top:
For me, a poor man and an enthusiast, let's say novelties, in Central Europe the computer ages after five years. Then the computer for free throws into the bucket and begins the path of cost-effective recycling to Asia. For me, an inconceivable fact.
I remember the times when Intel's new processors debuted on the market every two weeks. It was a market. The world is changing and for sure it isn't an era of Intel.
https://pclab.pl/zdjecia/artykuly/blind/2015/03/skylake/intel2.PNGhttps://www.fudzilla.com/images/stories/2016/April/intel-avx-512.jpg
https://linustechtips.com/main/topic/379471-intels-skylake-cpus-for-pcs-wont-support-avx-512-aka-avx3/

Or you mean every two years?

And as said before Skylake or whatever lake Intel has, has little to do with AVX support. All the Pentium / Celeron CPU don't support AVX, even thought they are Skylake +.

We only have to wait a few more years. We finally have a decent alternative to Intel x86.

Tommy Carrot

30th July 2018, 13:53

Well, "B-frame pumping" already existed in MPEG-2 times.
The effect is similar, but with a bigger gap. The b-frame thing occured in every 3rd frame or so, the golden frame boost happens in every 16th or so frame, and with a way higher quality boost. These factors make the ""pumping" effect more apparent. It could be tuned to be less noticeable, but that would worsen the metrics, so i doubt they would consider it.

mzso

30th July 2018, 15:11

Maybe so, but it definitely has some disadvantages too. Golden frames are very noticeably higher quality than the rest of the frames, so they can cause uneven, fluctuating quality (the finer details are vanishing and coming back periodically). This can be rather distracting if you start noticing this tendency.

Granted, AV1 is much better in this regard than VP9, but this issue is still there.

Actually I noticed this phenomenon with (rather poor) AVC videos before, from twitch I think. Don't remember noticing it with VP9 stuff.

mzso

30th July 2018, 15:13

We finally have a decent alternative to Intel x86.

Oh? What is that?

RussianNeuroMancer

30th July 2018, 15:21

But again, I have literally no idea if Ryzen APUs support HSA and hUMA, and I've even tried researching the subject.Not supported (http://rocm-documentation.readthedocs.io/en/latest/Installation_Guide/Installation-Guide.html)AMD Raven Ridge APU are currently not supported

A little bit of history on HSA topic: post 1 (https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/amd-linux/1025112-amd-will-continue-maintaining-multiple-compute-stacks-for-linux?p=1025309#post1025309), post 2 (https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/amd-linux/1034534-amdkfd-looking-to-be-merged-into-amdgpu-linux-drm-kernel-driver?p=1034729#post1034729), post 3 (https://github.com/RadeonOpenCompute/ROCm/issues/132#issuecomment-312926987) (John Bridgman is AMD HSA Linux architect).

In conclusion, I believe what industry possibly need in the future is AV1 decoder implementation on Vulkan compute, that will work on ARM and Intel-based devices too (in contrary to HSA implementation). However, I think that GPU hybrid implementations will quickly sunset such efforts (attempts to implement AV1 decoder on OpenCL, Vulkan, CUDA, etc.) and make them obsolete. Eventually hybrid implementations will be replaced by more complete hardware solutions, while legacy devices will continue to decode either AV1 on CPU or recieve VP9 or H264 stream for decoding on GPU, exactly as they do now. We seen how this play out with H264->VP9 transition and I don't think this time may be different.

LigH

30th July 2018, 21:45

The b-frame thing occured in every 3rd frame or so...

Then I used the wrong term; let's call it "GOP pumping" instead. DVD GOPs usually have a duration of half a second. And some MPEG-2 (hardware?) encoders prefer the I frame over all the following P and B frames with finer quantization. This effect was quite similar to your Golden Frame issue.

Tommy Carrot

30th July 2018, 22:17

Then I used the wrong term; let's call it "GOP pumping" instead. DVD GOPs usually have a duration of half a second. And some MPEG-2 (hardware?) encoders prefer the I frame over all the following P and B frames with finer quantization. This effect was quite similar to your Golden Frame issue.
Ah, gotcha. Indeed, it's very similar, especially in VP9 (mzso, watch something hard to compress on youtube, like fast moving gameplay footage, or something with a lot of foliage, you'll see). It's much more subtle in AV1, but still noticeable in some cases.

foxyshadis

31st July 2018, 04:33

Oh? What is that?

ARM64 is a darling in some circles, but it's hardly perfect, and it's even more segmented than the x64 market. You can't get AVC on some x64, but you can't be guaranteed NEON at all (which is like saying you can't get MMX/SSE) on some ARM64. That market is weird. It's also having serious scale-up issues, like everyone else who tries to make silicon go fast.

Xeon Phi has its diehards, but the SPARC route of lots of intermediate-powered chips hasn't set the world on fire. Intel appears to be abandoning the Knights platform, and moving toward doing things with superfast flash (Optane) mixed into a mesh of micro-CPUs. We'll see if that pans out any better.

And then, of course, there's GPU. There are people out there who want to ditch the CPU entirely for the GPU, or at least give it an even larger role than it already grabs in today's computing. There's a metric buttload of research on this, everything from new languages to on-the-fly recompiling x86 code into shaders that can run massively parallel, but the current hybrid solution is the current solution for a reason. It works, it's cheap, and it's accessible. Vulcan, OpenCL, and CUDA have proven to be powerful glue languages that specialize in what they can do very well, and fall over when asked to compute loops with side effects. Toss in a chip to do that processing faster, and hey, you have an underpowered CPU in the middle of your GPU! Like fixed-function video decoders, though, the case may be that such a thing could evolve and slowly push out the overkill system CPU, absorbing the CPU into the GPU instead of vice versa (or most likely, both in parallel). It doesn't take a genius to understand that if SIMD width keeps doubling, you're basically starting to process textures. As long as gamers and coin miners keep buying wildly overpowered GPUs for overspecced monitors, though, the state of the art will keep being advanced.

Oh, and quantum computing. Google's Bristlecone set a fire in the breasts of many a nerd, but we're probably almost a decade off from getting any derivative in an average joe's hand, even by cloud computing. Researchers are going to be grappling with what the hell to do with these for decades. Some brilliant folks are going to have their name immortalized in the coming years, but quantum has only just graduated from "nuclear fusion" territory.

foxyshadis

31st July 2018, 04:47

I believe someone explained before that the golden frame was kept consciously, and that it's no is not only not a disadvantage, but on the contrary it allows to do some stuff that otherwise wouldn't be possible.

Golden frames are technically superior to ref-frames in every way. It's just that no one's actually taken advantage of that superiority, just like as far as I know no one has taken advantage of long-refs in HEVC to minimize the impact of scenecuts, especially repeated scenecuts. The reduced refs HEVC gives you does take some of that flexibility away though.

LigH

31st July 2018, 15:44

New upload:

AOM v1.0.0-262-gbc484c485 (https://www.mediafire.com/file/miotmxp7csnsfav/aom_v1.0.0-262-gbc484c485.7z)

IgorC

1st August 2018, 01:01

rav1e is just on early stage of development
https://twitter.com/fg118942/status/1022425990276952064
https://pbs.twimg.com/media/DjBi2mdU8AEq8wv.png

MoSal

1st August 2018, 01:50

rav1e is just on early stage of development

It is. It's not even compatible with the final AV1 spec yet (getting close). And some encoding tools are not implemented or optimized for quality yet.

The encoder will be immediately interesting for its speed. The quality will (hopefully) come later. And by quality, I mean subjective quality.

marcomsousa

1st August 2018, 10:02

I'm trill by this new video codec (AV1), but also with the image (av1-avif (https://aomediacodec.github.io/av1-avif/)) brought by the same Alliance.
This AVIF image codec it's better that WebP.

You can compare the image AV1-AVIF with other formats here (http://wyohknott.github.io/image-formats-comparison/#abandonned-factory). (Select the AV1-2018 version)
You can also compare the video AV1 with other formats here (https://wyohknott.github.io/video-formats-comparison/).

It's very good that it begins new implementation of AV1, but how an encoder (rav1e) can make this statement?
The fastest and safest AV1 encoder.
If it's on early stage, is experimental, and not caught up with the release version.

About the AV1 roadmap
We just complete phase 1.
In 1 year we complete phase 2.
In 2 to 3 years we complete phase 3.
In 4 to 5 years we complete phase 4.

https://forum.doom9.org/attachment.php?attachmentid=16445&stc=1&d=1533115434

nevcairiel

1st August 2018, 10:16

Its safe because its written in Rust, which has fundamental type and memory safety built-in.

Nintendo Maniac 64

1st August 2018, 21:18

Not supported (http://rocm-documentation.readthedocs.io/en/latest/Installation_Guide/Installation-Guide.html)

ROCm is actually something different from HSA/hUMA as you can see that it also lists "Carrizo" APUs as 'Not Supported' even though Carrizo was in fact the first APU with full HSA/hUMA support (AMD would advertise Kaveri, the gen before, as only having "HSA features").

The additional transistor budget also allows Carrizo to become the first processor in the industry designed to be compliant with the HSA 1.0 specification developed by the HSA Foundation.

----------------------------------------------------------------

We finally have a decent alternative to Intel x86.
Oh? What is that?
ARM64 is a darling in some circles...And then, of course, there's GPU.

I'd just like to point out that all Ryzen processors support AVX2, and this even includes the lowly Ryzen 3 2200U and Ryzen Embedded V1000 (both of which are 2core/4thread parts much like their Pentium equivalents). I'm not sure how much Doom9-ers keep up with PC hardware news, but Intel has made a major fumble with their 10nm node which has left the door wide open for AMD's Zen2 + 7nm architecture to quite possibly clean house next year.

And of course, most of the lower core-count Ryzen parts (4c/8t and less) also have a relatively powerful iGPU as well (there's only a few 4core Ryzen parts that lack an iGPU, and they're all on desktop anyway).

Also, technically this isn't a "finally" as AMD was very competitive with Intel in the first half of the 2000s (Athlon XP to Athlon 64 x2) as well as with the late 2000's Phenom II parts (particularly the Phenom II x6). It's only been since 2011 with Intel's release of Sandy Bridge and AMD's "Faildozer" that Intel became so absolutely dominant in the CPU space.

...unless you were talking about the ISA of x86, in which case you can largely ignore everything I just said. :P It is worth pointing out though that 64bit x86 (that is, "x86-64") is actually an AMD creation and therefore both Intel and AMD cross-license with each-other.

But in other non-x86 related news, both AMD and Nvidia not only make ARM CPUs but are also part of the RISC-V Foundation.

benwaggoner

2nd August 2018, 19:04

It is. It's not even compatible with the final AV1 spec yet (getting close). And some encoding tools are not implemented or optimized for quality yet.
No encoding tools are well optimized for quality yet! HEVC is several years older and is still seeing substantial year-on-year perceptual quality improvements. I'm estimating we're 1+ year away from a "reasonably good" AV1 encoder, based on past encoder development.

For example, all the strobing concerns mentioned above. That's not an issue in the bitstream format at all, just about encoder implementation. It'll get addressed with better psychovisual tuning via adaptive quantization.

FWIW, my read on Golden Frames is that it started as an alternative way to get some of the advantages of b-frames and multiple reference frames while staying clear of IP around those technologies.

MoSal

2nd August 2018, 19:57

No encoding tools are well optimized for quality yet!

What I meant was, they are not finished with rudimentary implementations of the basic tools necessary to produce a compatible bitstream yet. There are a lot of things to do before they can even start caring about competitive quality.

Quikee

2nd August 2018, 22:42

No encoding tools are well optimized for quality yet!

Right, but there is --tune=psychovisual option already, which enables optimizations that improve visual and hurt metrics (using cdef-dist for RDO), but this was already implemented for libaom.

OTOH it doesn't even have inter prediction yet, which is the reason it performs so badly.

hajj_3

3rd August 2018, 12:15

Chrome 69 Beta has been released with support for decoding AV1.

birdie

4th August 2018, 10:06

Chrome 69 Beta has been released with support for decoding AV1.

Firefox 63 as well.

mandarinka

4th August 2018, 20:34

I believe someone explained before that the golden frame was kept consciously, and that it's no is not only not a disadvantage, but on the contrary it allows to do some stuff that otherwise wouldn't be possible.

Golden frame was the goto thing they could point at when they wanted to pretend VP8/9/... is a result of an extensive independent research and novel ideas of On2's and not just a crippled H.264/HEVC copy with some arbitrary changes and mangling made so that it is harder to sue. :devil: When your competitor makes everything in the open and drafts are available years in advance...

dapperdan

5th August 2018, 07:55

Golden frame was the goto thing they could point at when they wanted to pretend VP8/9/... is a result of an extensive independent research and novel ideas of On2's and not just a crippled H.264/HEVC copy with some arbitrary changes and mangling made so that it is harder to sue. :devil: When your competitor makes everything in the open and drafts are available years in advance...

Live by the patent, die by the patent.

If your entire business model is based on the public granting you property rights over a specific bit of mathematics in return for publishing the exact limits of your property, it's a little bit churlish to complain that the public makes use of that information. If that deal didn't suit then they shouldn't have taken it.

mandarinka

7th August 2018, 02:04

I don't buy the "it's only math" as an argument that video compression technology is simple and should not be patentable.

Everything is obvious in hindsight/to laymen, but to get to that hindsight situation is the hard part. MPEG/VCEG circles brought amazing video technology forward, if you recall how bad the codecs were say in 2004 (and those were already things brought forward by them and those were already great progress above truly stone age tech).

As in many fields and situations, people take all good things for granted, ignore their value and endlessly bitch about some trifling small details they find on them to complain about. (Yes, the neverending rants about licensing and royalty-free/encumberedness broken record, I consider that unimportant in the overall scope of video compression progress - to be clear.)

mzso

7th August 2018, 07:44

Blue_MiSfit

8th August 2018, 00:53

Let's not go down this rabbit hole, please :) Let's keep discussion on AV1.

IgorC

8th August 2018, 23:34

I apologize for an offtopic.
if you recall how bad the codecs were say in 2004
Ateme H.264 encoder was already state of the art with an excelent physocvisual model in 2004. It took x264 some long time to reach that quality.

LigH

9th August 2018, 15:03

New upload:

AOM v1.0.0-359-g1bc580401 (https://www.mediafire.com/file/f1b2sm00ydtglcx/aom_v1.0.0-359-g1bc580401.7z) (MSYS2; MinGW32: GCC 7.3.0 / MinGW64: GCC 8.2.0)

Tommy Carrot

9th August 2018, 16:56

:thanks:

The latest build crashes at the third frame in each attempt, no matter what settings i try. Anyone else have this happening? The 32 bit version works fine, so i dont know if it's because some bug in the code, or because of the new GCC.

LigH

10th August 2018, 07:36

Confirming on an AMD FX-6300. First pass passes; second pass gives an APPCRASH: Exception at 0x00000000004D3B68 in aomenc.exe: 0xC0000005: Access violation while reading at address 0x0000000000000000

A kind of "over-optimization" bug in GCC 8.2.0 is quite probable, IMHO. I wonder where to discuss it best. Will use the good old IRC for a while.
_

P.S.: There is a channel #aomedia on Freenode; I wonder why it is missing in the server's channel list, though... — Probably to avoid spam bots.
_

P.P.S.: It's probably an issue with the auto-vectorization (https://bugs.chromium.org/p/aomedia/issues/detail?id=2055). Let's see whether Alexpux can downgrade or upgrade GCC in MSYS2...

LigH

12th August 2018, 19:35

The issue has been analyzed down to a disassembly proving that Tree SLP Vectorization may produce undesired unaligned memory access, causing a segmentation fault.

There is a temporary patch proposed which rearranges some code to avoid this misalignment. Furthermore, I tried to notify the GCC developers of this issue. So until GCC 8 got fixed, aomedia may try to circumvent it sooner.

LigH

17th August 2018, 14:46

New upload:

AOM v1.0.0-399-g427b0382d (https://www.mediafire.com/file/bf4jtrfep9gc9k3/aom_v1.0.0-399-g427b0382d_noVO.7z) (MSYS2; MinGW32: GCC 7.3.0 / MinGW64: GCC 8.2.0; -fno-tree-slp-vectorize)
_

I have no experience creating a real .diff file; but if you want to do the same in MABS, a snippet for build/media-suite_compile.sh would look like:

if { [[ $aom = y ]] || { [[ $ffmpeg != "no" ]] && enabled libaom; }; } &&
do_vcs https://aomedia.googlesource.com/aom; then
- extracommands=()
+ extracommands=(-DAOM_EXTRA_C_FLAGS="-fno-tree-slp-vectorize" -DAOM_EXTRA_CXX_FLAGS="-fno-tree-slp-vectorize")
[[ -n $_aom_bins ]] && _check+=(bin-video/aomdec.exe) ||
extracommands+=(-DENABLE_EXAMPLES=off)

It could possibly be optimized to include these extra flags only in the 64 bit branch.

Tommy Carrot

17th August 2018, 18:23

Thanks for the new build, and for finding out what went wrong with the previous. No crashes so far, and while it's still very slow, the encoding speed is getting a bit better (though the quality has regressed a bit in some cases compared to the earlier builds).

I tinkered around with rav1e (the other av1 encoder) a bit too. It's definitely in a much earlier stage of development, it's still missing way too many features to have acceptable quality. But at least it produces valid bitstream.

TD-Linux

18th August 2018, 04:01

rav1e now has automatic Windows builds via Appveyor. To get the latest build, go to this page:

https://ci.appveyor.com/project/tdaede/rav1e/history

Click the latest build labeled with "master", then click Artifacts to download the executable. I'll wire up a better interface for some at this point.

Keep in mind that rav1e is still incomplete, lacking features such as motion compensation, so you should not expect good compression performance. However, it is much faster than libaom and is useful for generating long AV1 test sequences.

Selur

18th August 2018, 15:20

@TD-Linux: does rav1e support y4m input via pipe?

TD-Linux

18th August 2018, 20:40

Yes it does - just use a "-" to indicate pipe. You can also output ivf via a pipe. For example:

ffmpeg -i file.webm -f yuv4mpegpipe - | rav1e - -o file.ivf

olduser217

21st August 2018, 13:17

Hi guys, does the bit distribution of AV1 similar to VP9?

For VP9 4k bitstream in Youtube, according to requirement from Youtube, the decoder needs to support up to 65-frame decoding frame rate for 60-frame display frame rate, where there are up to 5-frame decoded without display.
These non-display frames are normally acting as ALTREF frame for the decoding of frames decoded after it, and they are normally being allocated with lot of bits compare to other inter frames (more than 10 times) which will be displayed.

Netflix VP9 bitstreams seem like having such bit distribution too.

Does the same happen to AV1?

v0lt

21st August 2018, 16:50

TD-Linux

22nd August 2018, 01:28

For VP9 4k bitstream in Youtube, according to requirement from Youtube, the decoder needs to support up to 65-frame decoding frame rate for 60-frame display frame rate, where there are up to 5-frame decoded without display.
These non-display frames are normally acting as ALTREF frame for the decoding of frames decoded after it, and they are normally being allocated with lot of bits compare to other inter frames (more than 10 times) which will be displayed.

Netflix VP9 bitstreams seem like having such bit distribution too.

Does the same happen to AV1?

Yes, see section A.3 of the spec. MaxDisplayRate and MaxDecodeRate are different, with MaxDecodeRate being higher. Note that this is more flexible than VP9 - if you are at a lower resolution or frame rate, you can use more non-shown frames. There is also a maximum header rate defined separately.

olduser217

22nd August 2018, 01:32

Where did you get this very questionable information?

https://sites.google.com/a/google.com/youtube-leanback-partners/evaluation/2019-technical-requirements?pli=1

You probably need to join the group to access it.

You can simply download a 4k 60fps VP9 bitstream from Youtube to check the existence of such non-display frames (show_frame == 0), which are added around or close to the frequency mentioned.

olduser217

22nd August 2018, 01:46

Yes, see section A.3 of the spec. MaxDisplayRate and MaxDecodeRate are different, with MaxDecodeRate being higher. Note that this is more flexible than VP9 - if you are at a lower resolution or frame rate, you can use more non-shown frames. There is also a maximum header rate defined separately.

Yes, noticed about this too.
So, for Level 5.1 of AV1 (seems like suitable for 4k60), the maximum decode frame rate for 3840x2160 equals to:
= MaxDecodeRate/3840x2160
= 547,430,400 / 3840x2160
= 66fps

So, the frame rate for decoding is quite similar to VP9 (at least for Youtube case).

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.

Blue_MiSfit

22nd August 2018, 21:02

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

22nd August 2018, 22:01

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

23rd August 2018, 10:29

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

23rd August 2018, 11:03

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

23rd August 2018, 13:25

AV1 will be disable in Chome 69.

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

https://chromium.googlesource.com/chromium/src.git/+/3416497c874e5f121ade527e6796192818654436

v0lt

25th August 2018, 13:57

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.