Versatile Video Coding (VVC) / H.266: HEVC successor

[pandy]

https://jvet.hhi.fraunhofer.de/

Up to 64 more computationally complex than H.265 for encoding and perhaps even 16x times for decoding...

Any thoughts?

[burfadel]

Needs to be more efficient than that time wise.

[Jamaika]

I know for sure. HEVC codec discouraged me from Fraunhofer. There was a long decoding time in JCT-VC codecs used in BPG images.
http://hevc.kw.bbc.co.uk/git/w/jctvc-hm.git

For me another new codec

[hajj_3]

https://jvet.hhi.fraunhofer.de/

Up to 64 more computationally complex than H.265 for encoding and perhaps even 16x times for decoding...

Any thoughts?

where does it say that?

[sneaker_ger]

The increase of computational complexity compared to HEVC is reflected by the fact that
the encoder software run time increases by factors of approximately 12 and 60 in RA and
AI configurations, respectively. Correspondingly, the decoder run time increases by factors
of approximately 10 and 2.5 in RA and AI, respectively. These are average numbers over
the entire set of sequences from [3]. The worst case complexity may even be more dra-
matically higher compared to HEVC.
https://show.ibc.org/__media/Technical-Papers-2017/JR-Ohm---STATUS-AND-PERSPECTIVES-OF-VIDEO-CODING.pdf

[hajj_3]

https://show.ibc.org/__media/Technical-Papers-2017/JR-Ohm---STATUS-AND-PERSPECTIVES-OF-VIDEO-CODING.pdf

• Submission deadline: February 2018.
• Evaluation of responses: April 2018.
• First test model: October 2018.
• First version of new video compression standard: October 2020.

does this mean that october 2020 is when it would be ratified or does this happen at some point after the "first version"?

[benwaggoner]

https://jvet.hhi.fraunhofer.de/

Up to 64 more computationally complex than H.265 for encoding and perhaps even 16x times for decoding...

Any thoughts?
Encoding time in a reference encoder doesn't really matter. 64x generally means it has 64x more ways to do things than HEVC, but real-world encoders aren't going to do an exhaustive search of all those modes! They'll use heuristics and early exits to deliver as good quality as possible within available time. As encoders have always done since the beginning of time. x265 is >>100x faster than the HEVC HM reference encoder even with --preset slower, for example.

Decoder time of 16x would be a huge problem. HEVC was carefully designed to have no more than 2x the complexity of H.264 even with all the options on. No one would ever come out with a video codec standard that requires 16x the silicon area or clock speed or memory or anything. Even MPEG-2 -> HEVC was only about 4x the decoder complexity per pixel at a given quality.

[iwod]

What sort of bitrate reduction are they expecting?

[sneaker_ger]

At this point they don't seem to have set any public goal and instead say it's a "study" to see what may be possible with new tools.
As of the current status, the bit rate reduction of JEM6, when compared to an HM16 soft-
ware encoder implementing the HEVC Main 10 Profile, is around 30 % in Random Access
(RA) configuration using motion compensation in a hierarchical B picture structure, and
around 20% in All Intra (AI) configuration (without motion compensation). This result was
obtained when averaging the bit rate reduction comparing at same PSNR by the so-called
Bjøntegaard Delta criterion
[...]
Measuring PSNR can be misleading as a criterion for judging quality. In order to assess
the subjective visual benefit, expert viewing tests were performed during the 7 th JVET
meeting in the context of evaluating responses to the Call for Evidence[...]Typically, bit
rate savings at same visual quality of between approximately 35 and 60% were observed.

Just read the doc from post #5 ...

[iwod]

At this point they don't seem to have set any public goal and instead say it's a "study" to see what may be possible with new tools.


Just read the doc from post #5 ...

Great, the Web site were...ugh.

It is good they recognized they have an Open Source and Free Codec competition. Since they have gobbled up enough money with H.265 I hope they sort out their license fees and structure first BEFORE moving on.

Edit: I know that is not the purpose of the study. But they surely need to keep this in mind.

I am on the HEVC side for now, this is simply because it is the only choice. I dont think AV1 will go anywhere. But AV2, I hope they get it right.

[pandy]

Encoding time in a reference encoder doesn't really matter. 64x generally means it has 64x more ways to do things than HEVC, but real-world encoders aren't going to do an exhaustive search of all those modes! They'll use heuristics and early exits to deliver as good quality as possible within available time. As encoders have always done since the beginning of time. x265 is >>100x faster than the HEVC HM reference encoder even with --preset slower, for example.

Decoder time of 16x would be a huge problem. HEVC was carefully designed to have no more than 2x the complexity of H.264 even with all the options on. No one would ever come out with a video codec standard that requires 16x the silicon area or clock speed or memory or anything. Even MPEG-2 -> HEVC was only about 4x the decoder complexity per pixel at a given quality.

But when we compare x264 and x265 then increasing complexity of the JET looks quite unpleasant... I know that overall trend is to use more threads but still - increasing computational complexity (exponentially) quickly become serious issue.
Those 64x and 16x are just worse case scenario a bit exaggerated figures.
In 80 when MPEG-1 (and later 2) was born every 2 - 3 years CPU computational power was almost doubled, now we observe severe stagnation on this - rarely new CPU's are providing more than 20% processing gain...

[bstrobl]

But when we compare x264 and x265 then increasing complexity of the JET looks quite unpleasant... I know that overall trend is to use more threads but still - increasing computational complexity (exponentially) quickly become serious issue.
Those 64x and 16x are just worse case scenario a bit exaggerated figures.
In 80 when MPEG-1 (and later 2) was born every 2 - 3 years CPU computational power was almost doubled, now we observe severe stagnation on this - rarely new CPU's are providing more than 20% processing gain...

We are slowly romping up against physical limits of chip production, and codec development is doing pretty much the same. Many of the changes are now an attempt at trying to discern an improvement or if its just noise due to the huge amounts of coding tools and their tiny contribution. At some stage it simply won't be worth upgrading codecs due to insane encode/development costs.

The JET folks really need to sort out their licensing mess though since AV1 can encode similar quality when compared to HEVC at 75% of the bitrate. Granted, AV1 seems a bit rushed but as long as most of the nagging issues from VP9 are fixed more people will hop onto it and stay if patent costs keep increasing with the h.26x codecs.

[iwod]

But when we compare x264 and x265 then increasing complexity of the JET looks quite unpleasant... I know that overall trend is to use more threads but still - increasing computational complexity (exponentially) quickly become serious issue.
Those 64x and 16x are just worse case scenario a bit exaggerated figures.
In 80 when MPEG-1 (and later 2) was born every 2 - 3 years CPU computational power was almost doubled, now we observe severe stagnation on this - rarely new CPU's are providing more than 20% processing gain...

Yes, and it also happens the world have moved to Mobile, and we dont use CPU to do decoding anymore, in most cases we are doing Hardware accelerated decoding with Specific Hardware or DSP, and it also happen they are 10x more efficient at doing so.

But i do understand the concern. If I remember x265 started off being 5x to 10x slower then x264. And the reference encoder were very slow.

I am mainly concerned about two things,

1. Real Time Encoding, that is if you are encoding a live sports like Football Match, I think we are running into some limitation there in regards to Speed / Bitrate and Quality.

2. Decoding: As benwaggoner mentioned, the decoding complexity hasn't increased much, MPEG-2 -> HEVC is only 4x per pixel, which is very little increase in that space when we had 10 - 20x computation power. What has increased though is we moved from 480P to 4K, that is ~20x Pixels.

Unless 3D, VR, or some other Killer Apps comes in, JET or AV2 will properly be the last video codec improvement we see. Pretty much like Audio Codec, bandwidth increase in 5G will means most of those bitrate saving being less of a concern.

[benwaggoner]

Unless 3D, VR, or some other Killer Apps comes in, JET or AV2 will properly be the last video codec improvement we see. Pretty much like Audio Codec, bandwidth increase in 5G will means most of those bitrate saving being less of a concern.
You know, I thought the same thing back in early 1997. We could almost deliver (analog 480i) broadcast quality on a CD-ROM! What was there left to do? I was actively planning my career pivot to film restoration.

Then Peter Jacobsen called up and asked if we can use this new RealVideo beta thing to embed some golf clips into his web site without buffering.

xHE-AAC is a big material improvement for important markets. We could have 10x the efficiency of HEVC today and deliver pristine UHD HDR over 4G networks.

Or deliver a great full-screen experience over a 2G network to people riding a bus in rural India. 720p @ 20 Kbps would still be a worthwhile improvement over 720p @ 30 Kbps.

I am confident that incremental improvements in compression efficiency will remain a multi-billion dollar market through my retirement. The main thing that could cause things to slow down is if we really hit a wall in terms of silicon process nodes, and stop getting big year-on-year MIPS per watt gains. If we were stuck on the same node, we might start running out of exciting new things to do after a decade or so.

There is still a huge market for improved MPEG-2 encoders...

[benwaggoner]

But when we compare x264 and x265 then increasing complexity of the JET looks quite unpleasant... I know that overall trend is to use more threads but still - increasing computational complexity (exponentially) quickly become serious issue.
Those 64x and 16x are just worse case scenario a bit exaggerated figures.
The real comparison should be quality at equal perf. If a codec offers a 100% improvement at 64x encoding time, but a 50% improvement at the same encoding time, it's still a big win. I doubt anyone is doing HEVC with the same coverage of theoretical options as they do with H.264, but HEVC still delivers some big real-world efficiency improvements at practical speeds.

These theoretical encoding times are really JM versus HM; encoders which are far too slow for any practical use, and really not very good psychovisually. And for decoder complexity, that's what Profiles and Levels are for. If there is a 16x worst case, probably 85% of the practical efficiency gains can be found in the first 2x of decoder complexity. Hitting the right balance between efficiency gains and decoder complexity is a huge part of designing a major bitstream format, and one of the reasons that the MPEG/ITU codecs are so good. There are just so many eyeballs from so many different industry sectors pounding on it to squeeze every last bit and MIPS out.

In 80 when MPEG-1 (and later 2) was born every 2 - 3 years CPU computational power was almost doubled, now we observe severe stagnation on this - rarely new CPU's are providing more than 20% processing gain...
Per core and for general compute, perhaps. But whenever a chip is "5-40%" faster, video encoding is the 40%. Because we can go widely parallel, and use SIMD instructions like AVX2 harder than about anything. And the good implementations get so much hand-tuned assembly optimizations.

The new 8th gen Core processors look to offer ~2x encoding throughput per dollar and per watt. More cores, less thermal throttling using AVX/AVX2, microarchitectural improvements, and hopefully some value in AVX512.

This is a bigger leap than most generations, but a slowdown in Moore's law will hit video the least and latest of almost technology.

[LigH]

At the moment, the sources appear to be available with building solutions for some MSVC versions and a makefile for Linux; would it be hard to adapt the latter for MSYS/MinGW? I would ask that in their repo as well...

[nevcairiel]

Linux makefiles is what MinGW uses.

[LigH]

I just don't know if they require some quirks in details; Multicoreware has separate build files for msys and linux, that may be related to CMake though...

[foxyshadis]

It seems like hikvision is the only one who's shown any interest this year, and I actually know a few people there. I should reach out and see what they're working on; aside from that, the project is essentially dead. I guess improving HEVC is still the only priority for all the big research companies.

[qyot27]

I just don't know if they require some quirks in details; Multicoreware has separate build files for msys and linux, that may be related to CMake though...
They do that for 'convenience' (although whose convenience is beyond me), not because it's anywhere near necessary. I've never used those build scripts for either Linux or cross-compiled MinGW builds - there's virtually no difference in how to configure CMake, which is all those scripts even do anyway - they're not actual Makefiles or MSVC solutions, only .sh and .bat scripts to tell CMake to use the Makefiles or Visual Studio generators.

The only thing that presents an actual need to configure them differently is that MinGW requires specifying a cross-compiling toolchain file - and that's only necessary when actually cross-compiling (read: Linux, OS X, or Cygwin, not MSys2).

[LigH]

So, chances are good that the makefile will work with the native compiler set of either MinGW32 or MinGW64 ... maybe I try to compile it then. Despite the last change being half a year old.

[colinhunt]

^ I'd be interested in testing the binary if you manage to compile one.

[LigH]

Unfortunately I did not. There are some errors (several "enum constant in boolean context" warnings treated as errors in extlib/Eigen/src/Core/Assign.h). I may get further if I knew how to disable this strictness?!

Paste: JVET JEM rev. 595 in MinGW64 (https://pastebin.com/Z3JJ2bft)

[LigH]

I commented out the CPPFLAGS option "-Werror" in build/linux/common/makefile.base to get the software built anyway; so expect it to break later... :o

JVET (https://www.mediafire.com/?pdekmpyk4e61m) rev. 595 (HM-16.6-JEM-7.1) — small archive for the minimum software selection, large only for the curious

[Tommy Carrot]

Thanks for the build, so far it's working without any crashes. I cant say anything about the quality yet, but the encoding speed is not that bad. I mean it's very slow, but not AV1 slow. :D

Edit: nevermind, on a higher resolution (720p) test encoding, it's much slower in comparison, the encoding speed is around halfway between AV1 --cpu=used=0 and --cpu-used=1. The quality at low bitrate is VERY impressive though. Easily better than AV1 or XVC.

[iwod]

It seems like hikvision is the only one who's shown any interest this year, and I actually know a few people there. I should reach out and see what they're working on; aside from that, the project is essentially dead. I guess improving HEVC is still the only priority for all the big research companies.

I thought they have some Demo in NAB?

[LigH]

I do not even know what "NAB" means; but yes, it was reported in the thread about AOM.

[nevcairiel]

"National Association of Broadcasters", they just had their tradeshow last week where content creators and codec people like to show off.

[LigH]

Could a moderator please fix the typos in the thread title, as I reported a few days ago?

[Tommy Carrot]

I've done some more tests with this codec. It's unfortunate that even if they finish the development it's probably doomed because of patents and licensing issues, because from a technical standpoint, it seems to be significantly better than AV1. It has consistently better (and more consistent) quality, in some cases by a pretty big margin.

[hajj_3]

I've done some more tests with this codec. It's unfortunate that even if they finish the development it's probably doomed because of patents and licensing issues, because from a technical standpoint, it seems to be significantly better than AV1. It has consistently better (and more consistent) quality, in some cases by a pretty big margin.

The other big problem is that it will be ratified 2.5yrs after AV1. There will be huge numbers of phones, tablets, laptops, desktops, tvs etc with hardware decoders shipping by the time h.266 is ratified. I reckon within 1yr of h.266 is ratified that AV2 will be ratified, which will likely have 0-15% better compression than h.266.

[colinhunt]

JVET (https://www.mediafire.com/?pdekmpyk4e61m) rev. 595 (HM-16.6-JEM-7.1) — small archive for the minimum software selection, large only for the curious
Thanks!

[iwod]

The other big problem is that it will be ratified 2.5yrs after AV1. There will be huge numbers of phones, tablets, laptops, desktops, tvs etc with hardware decoders shipping by the time h.266 is ratified. I reckon within 1yr of h.266 is ratified that AV2 will be ratified, which will likely have 0-15% better compression than h.266.

Nearly 1.4 Billion of Smartphone, 150M Tablet, 250M Notebook and Desktop. 200M of TV, Camera, STB, and other consumer electronics combined per year

That is 2 Billion unit every year from Consumer Market. Excluding the professional uses.

If they only take 50 Cents / unit, that is annual $1B revenue stream. If you expect the codec to last 10 - 20 years, that is total $20 Billion return.

With No Cap. The more unit you sell the more you pay.

The software implementation should be free. I mean, the codec would now be so complex it is literally impossible to play without a top range general hardware or dedicated decoder. Along with free image format.

[augman000]

Thanks for the build, so far it's working without any crashes. I cant say anything about the quality yet, but the encoding speed is not that bad. I mean it's very slow, but not AV1 slow. :D

Edit: nevermind, on a higher resolution (720p) test encoding, it's much slower in comparison, the encoding speed is around halfway between AV1 --cpu=used=0 and --cpu-used=1. The quality at low bitrate is VERY impressive though. Easily better than AV1 or XVC.

I'm going to start doing some comparative testing of my oen today.

When you say "low bitrate", are you talking 512kbps or less? Also, have you gone below 480p in your low bitrate tests?

[Tommy Carrot]

I'm going to start doing some comparative testing of my oen today.

When you say "low bitrate", are you talking 512kbps or less? Also, have you gone below 480p in your low bitrate tests?

On low bitrate, generally i mean around or under the size of x264 crf 30. But i tested it waaaay lower and in normal range as well, on different clips. Generally my finding is that the lower the bitrate, the larger JVET's advantage is (especially on cartoon stuff).

However, be prepared that the encoder is very slow, and cannot read y4m, only raw yuv. I only had the patience to test it on few seconds long 720p and lower res videos. But as the encoder is single-threaded, you can run a couple encodings in parallel.

[augman000]

On low bitrate, generally i mean around or under the size of x264 crf 30. But i tested it waaaay lower and in normal range as well, on different clips. Generally my finding is that the lower the bitrate, the larger JVET's advantage is (especially on cartoon stuff).

However, be prepared that the encoder is very slow, and cannot read y4m, only raw yuv. I only had the patience to test it on few seconds long 720p and lower res videos. But as the encoder is single-threaded, you can run a couple encodings in parallel.

Sure, I've been playing around with AV1 for quite some time now, so I've learned to be very patient.

Tried to run a quick test on lunch with no luck. Could you give me a sample vommand line syntax? I obviously overlooked or misunderstood something when I looked over the usage info.

Thanks.

[Tommy Carrot]

Here is an example:
TAppEncoderstatic.exe -c config-samples\encoder_randomaccess_jvet10.cfg -q 25 -fr 25 -wdt 720 -hgt 288 -f 50 -i test.yuv -b jvet.bin

I encoded a 720x288 video at 25 fps, and encoded 50 frames in total. You have to set every parameter manually, the encoder is kinda dumb.

In the config file, i set the intra period to 256 frames, i think the default is too low.

[augman000]

Here is an example:
TAppEncoderstatic.exe -c config-samples\encoder_randomaccess_jvet10.cfg -q 25 -fr 25 -wdt 720 -hgt 288 -f 50 -i test.yuv -b jvet.bin

I encoded a 720x288 video at 25 fps, and encoded 50 frames in total. You have to set every parameter manually, the encoder is kinda dumb.

In the config file, i set the intra period to 256 frames, i think the default is too low.

Ah, I think I already see my mistake.

Yhanks for the help.

[hajj_3]

Could a moderator rename this thread please as this codec has an official name now 'Versatile Video Coding' (VVC): http://news.itu.int/versatile-video-coding-project-starts-strongly/

[LigH]

I wonder if a new source repo will be announced. The Fraunhofer JVEM SVN had a few updates to r599 to prepare a "transition to VTM".

[TomV]

Could a moderator rename this thread please as this codec has an official name now 'Versatile Video Codec' (VVC): http://news.itu.int/versatile-video-coding-project-starts-strongly/

Versatile Video Coding

[AntiqueRefrigerator]

so is the war about codecs changing from quality to cpu cycles? av1 seems to be barely better than hevc and takes 1000x longer. sure you can have more quality, but what about creation time? do we still care about that?

[iwod]

so is the war about codecs changing from quality to cpu cycles? av1 seems to be barely better than hevc and takes 1000x longer. sure you can have more quality, but what about creation time? do we still care about that?

If you look back at video codec history, CPU cycle questions were always on the table. The only difference is 20 years we didn't even know where the limits are, we thought we could infinitely scale, 10Ghz+ processors, or 64 Core CPU and parallelism would work out fine.

Now that we have reached a plateau, these questions becomes much more important.

[iwod]

http://blog.chiariglione.org/the-mpeg-machine-is-reasy-to-start-again/

Sounds like VVC is coming along nicely. I wish they could aim a little higher then the 50% improvement though.

There is another pieces about the problem of IP.

http://blog.chiariglione.org/ip-counting-or-revenue-counting/

[benwaggoner]

so is the war about codecs changing from quality to cpu cycles? av1 seems to be barely better than hevc and takes 1000x longer. sure you can have more quality, but what about creation time? do we still care about that?
No one cares about exhaustive search, which is where the orders of magnitude speed increases come for. Every tool has to get tested every way, so there's a combinatorial explosion.

The real metric is efficiency @ perf. If a new codec is able to deliver better quality in the same encoding time, that's a win. And as Moore's Law marches on, the number of MIPS/pixel we are willing to spend keeps going up up up.

x265 beats x264 for most scenarios with the same encoding time, AND it can provide much more efficient encoding for the patient.

Any new codec has to show that it can provide significant efficient gains in reasonable encoding time. And quality @ perf gets way better in the initial years after a new bitstream is defined as performance and psychovisual tuning gets done.

Increases in decoder complexity are a bigger barrier, since that goes to the cost of all those decoders in all those devices. If something takes 4x the silicon and milliwatts to decode versus an existing standard, it would have to be REALLY more efficient.

MPEG-2 -> H.264 -> HEVC were about 2x more complex per pixel, for about 2x better efficiency. Generally more complexity or lower efficiency gains don't really move the market (see MPEG-4 part 2, Theora, VP6-9)

[benwaggoner]

The other big problem is that it will be ratified 2.5yrs after AV1. There will be huge numbers of phones, tablets, laptops, desktops, tvs etc with hardware decoders shipping by the time h.266 is ratified. I reckon within 1yr of h.266 is ratified that AV2 will be ratified, which will likely have 0-15% better compression than h.266.
The delay of the bitstream freeze has pushed hardware AV1 decode back a year and we'll probably only see significant numbers of AV1 HW decode devices shipping in 2020. So if H.266 is looking promising by then, or if AV1 hasn't surpassed HEVC in quality @ perf, the big drivers of adoption might not happen. AV1's compression efficiency improvements are initially promising, but it needs to demonstrate significant gains versus HEVC in double-blind visual testing at similar encoding complexity.

Does anyone have any sense of the increased HW decoder complexity of AV1 versus HEVC, and how much is additive (versus the same decoder using the same functional blocks for multiple codecs)?

I worry that the current AV1 encoder is so slow that there really isn't a big enough corpus of encoded content to figure out what quality/efficiency delta could be anticipated in the real world in a given time frame.

The cost to add AV1 decode depends on the delta in silicon area and milliwatts. I've not heard any estimates for that delta yet. Anyone else? Obviously the cheaper the cost to add decode, and the bigger the relative value, are both going to be big factors in adoption.

[foxyshadis]

MPEG-2 -> H.264 -> HEVC were about 2x more complex per pixel, for about 2x better efficiency. Generally more complexity or lower efficiency gains don't really move the market (see MPEG-4 part 2, Theora, VP6-9)

I really believe that it's been closer to 1.4x quality for 2x complexity, at some "midrange" (when you insert ASP between MPEG-2 and AVC). Each generation gets 2x or more better at the low-end, and barely budges the needle at the top-end, but some magical middling rate that's barely objectionable is where codecs are really put to the test. HEVC easily qualifies for "not worth the hassle" except for its day-1 promise of built-in hardware-accelerated 10-bit and HDR; except at the absolute lowest bitrates it never comes close to living up to its half-rate promise. If AVC RExt had found its way into hardware, HEVC's use case would have been squeezed to nothing, considering the ongoing licensing spats, while the world again waited for the next world heavyweight champion to appear.

A quadratic increase in complexity for a linear increase in efficiency sucks, but that's what we have the remnants of Moore's law for.

[hajj_3]

https://streaminglearningcenter.com/codecs/impressive-early-results-versatile-video-coding-vvc.html

[LigH]

I am not able to build the "VTM Repository" (trunk) in MSYS2 / MinGW: If you try to create the Makefile with the CMake generator "MinGW Makefiles", it complains that sh.exe must not be in the path; if you try the generator "MSYS Makefiles", BBuildEnv.cmake warns that it is not fully supported, and make fails with:

jvet-svn/source/Lib/CommonLib/x86/CommonDefX86.h:158:71: error: SSE vector return without SSE enabled changes the ABI [-Werror=psabi]

It seems to be mostly optimized for Visual C++.

[Blue_MiSfit]

Does anyone have any sense of the increased HW decoder complexity of AV1 versus HEVC, and how much is additive (versus the same decoder using the same functional blocks for multiple codecs)?

I worry that the current AV1 encoder is so slow that there really isn't a big enough corpus of encoded content to figure out what quality/efficiency delta could be anticipated in the real world in a given time frame.


Well said. I'd like to see a lot more of this.

[benwaggoner]

Well said. I'd like to see a lot more of this.
I’m sure it’ll come. But I’m not really expecting to have a good sense of how AV1 and HEVC would compare for real-world scenarios before Q4 2019. HEVC is going to be better at quality @ perf for any real-world perf scenario for a long time. Getting all the inter and intra frame parallelization working is quite a project, and all the tuned vectorization (AVX2 & AVX512 these days).

This article on threading in x265 is an eye-opening read about the challenges of just parallelizing a modern codec. https://x265.readthedocs.io/en/default/threading.html

And just look at the sheer amount of ASM code in it https://bitbucket.org/multicoreware/x265/src/88ee12651e3031dc1fc2f3f6a8bbac5f67839579?at=default.

Given the greater complexity of AV1, it would take a greater equivalent effort to provide the same degree of optimization as x265 has after 5+ years of serious development.

[iwod]

https://streaminglearningcenter.com/codecs/impressive-early-results-versatile-video-coding-vvc.html

I am looking at the graph and table, which state VVC is currently only ~25% to 30% less bitrate than HEVC. May be it would flare better at 500Kbps and 1Mbps, but not too excited by it.

How about a codec that targets to similar or better quality than 1Mbps 720P HEVC @ 500Kbps, 2Mbps 1080P HEVC @ 1Mbps, 8Mbps 4K HEVC @ 4Mbps.

And as to patents fees, why cant they keep it simple? All software implementation should be free. $0.5 for hardware decoder and $1 hardware encoder, $1.25 for both and charged per unit. No Caps, there more you sell the more you pay. License includes all the previous HEVC and AVC patents.

That is combined to be $3B+ yearly revenue. On a twenty years target they are getting back ~$60B for their investment.

Edit: The software implementation being free meant we could have a image format implementation that is available free for the web. We need something to replace jpeg.

[foxyshadis]

I am looking at the graph and table, which state VVC is currently only ~25% to 30% less bitrate than HEVC. May be it would flare better at 500Kbps and 1Mbps, but not too excited by it.

How about a codec that targets to similar or better quality than 1Mbps 720P HEVC @ 500Kbps, 2Mbps 1080P HEVC @ 1Mbps, 8Mbps 4K HEVC @ 4Mbps.

It's like Moore's Law: The first few iterations are cheap, but you start running into fundamental limitations eventually.

I've been experimenting with long-term references, which are a promising avenue for video that flips from one viewpoint to another and then back (incredibly common), which can give significant savings in some scenes, but making this work within the profiles available is almost impossible. I have no idea why set-tops are limited to a handful of megabytes in 2018.

[Clare]

VVC – The Next-Generation Video Standard of the Joint Video Experts Team (https://youtu.be/9jCVAehMTRI)

[mandarinka]

VVC – The Next-Generation Video Standard of the Joint Video Experts Team (https://youtu.be/9jCVAehMTRI)

Thanks for pointing that out. It's starting to look really interesting, I'd say.

The slides should be here: http://mile-high.video/files/mhv2018/

[benwaggoner]

There was also some great data about VVC at the SMPTE Tech meetings in LA this week. Efficiency gains for objective metrics on HEVC HM are getting close to 30%, and the encoder is only about 1/5th slower. Subjective testing shows bigger gains than objective metrics predict. Theory is that the motion interpolation is a better match for the human visual system, so high QP motion artifacts aren’t nearly as objectionable. It’s always districting when things happen on a grid structure; our eyes are REALLY good at horizontal and vertical detail, and regular distributions.

Same track also showed that HEVC beats AV1 on subjective tests even

The goal of the same subjective quality as HEVC at half the bitrate looks within reach, given the bitstream has still more than a year to percolate. It might be more than 50% for UHD and higher resolutions.

(Although I still don’t think 8K video is going to really be a thing).

[LigH]

Any recent builds using MSVC? It still fails with "MSYS Makefiles".

[iwod]

http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/At-the-Battle-of-the-Codecs-Answers-on-AV1-HEVC-and-VP9-128213.aspx

The good news which I don't think had any media attention was the formation of Media Coding Industry Forum (MC-IF) for VVC. And from the start HEVC Advance and most of the Velos Media Companies are already included ( Missing Qualcomm ) as well as those who were previously not included in All three of the HEVC Pool such as technicolour and Nokia.

Lets hope they have learned their lesson with HEVC.

[SmilingWolf]

MSYS2/GCC 8.2 64bits only:
VVCSoftware_VTM-2.2-51ce2f5b: https://mega.nz/#!s5Q1GYAA!cUHFazHOoIqUIvVMciXCe9uL8KND0QvDfsLdl3Uhxf8

Unfortunately the parallel mode related code hasn't been updated after the introduction of JVET-L0266-HMVP, which means the function call at line 935 in EncCu.cpp (https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/blob/master/source/Lib/EncoderLib/EncCu.cpp#L935) fails to compile when enabling WPP and multithreading. So, single thread for now.

[Tommy Carrot]

Nice, thanks for the new build. The quality/efficiency seems to have improved slightly compared to the last build i have from april. Definitely better than AV1, the lower the bitrate, the bigger the difference is. It is slower than aomenc with its slowest preset though.

Definitely looks very promising quality-wise, i just hope the licensing shenanigans won't be repeated again.

[LigH]

How did you do that? Did you apply a custom patch? Would that work with GCC 7.3.0 too, or only with GCC 8.2.0?

[SmilingWolf]

First thing I did was modify line 99 in CMakeList.txt from
if( UNIX )
to
if( NOT MSVC )
which is the same thing aom does to set the compiler flags for GCC/ICC/Clang.

Then I had to add
add_compile_options( "-mavx2" )
right below
add_compile_options( "-msse4.1" )

All the above BEFORE the "cmake -G "MSYS Makefiles" -DBUILD_STATIC=ON -DCMAKE_BUILD_TYPE=Release .." command of course

However! This triggers something in GCC and the compilation process bugs out on IntraPrediction.cpp because of some -Wmaybe-uninitialized which appears ONLY when compiling with -mavx2
So what I do is, make -j6 until it bugs out, then make VERBOSE=1 to intercept the "bad" compilation command, remove -mavx2 from it, run that command, reposition myself at the top of the build directory, then resume building normally.
Gotta do the same thing twice because IntraPrediction.cpp is used in a couple of libraries, so the object file ends up in different directories each time.

Not the most straightforward way, but everything seems to work fine afterwards

[LigH]

:scared: Too much manual meddling for me as autobuild suite user... :o

I made it an official issue (https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/issues/1) and hope it will be taken seriously. :rolleyes:

At least it has a future. Unlike mencoder which may already be dead.

[SmilingWolf]

Well I did all that to stay on the "safe" side of things.

However one could modify line 75 in CMakeLists.txt from
bb_enable_warnings( gcc warnings-as-errors -Wno-sign-compare -Wno-class-memaccess )
to
bb_enable_warnings( gcc warnings-as-errors -Wno-sign-compare -Wno-class-memaccess -Wno-maybe-uninitialized )
along with the other CMakeLists.txt described above to enable SSE4.1 and AVX2. It compiles fine without manual intervention, altough I haven't tested yet the encoder built this way (just finished compiling).
There shouldn't be any problem though, -Wmaybe-uninitialized is known to be overzealous (https://stackoverflow.com/a/14132910) at times

Also, it's always strange to see my nick in quotes like 'SmilingWolf' or 'lupo...'. Makes me feel kinda like a shady character lol
Note that I don't mean anything by this. I'm merely too used to considering it my first name when I'm online

EDIT:
summing up, a git diff ready to apply to the repo looks like this:
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 2d59e74..3c3430c 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -72,7 +72,7 @@ endif()
# bb_enable_warnings( gcc -Wno-unused-variable )
# bb_enable_warnings( gcc-4.8 warnings-as-errors -Wno-unused-variable )
# for gcc 8.2:
-bb_enable_warnings( gcc warnings-as-errors -Wno-sign-compare -Wno-class-memaccess)
+bb_enable_warnings( gcc warnings-as-errors -Wno-sign-compare -Wno-class-memaccess -Wno-maybe-uninitialized )

if( XCODE )
bb_enable_warnings( clang warnings-as-errors
@@ -96,8 +96,9 @@ endif()
bb_enable_warnings( msvc warnings-as-errors "/wd4996" )

# enable sse4.1 build for all source files for gcc and clang
-if( UNIX )
+if( NOT MSVC )
add_compile_options( "-msse4.1" )
+ add_compile_options( "-mavx2" )
endif()

# enable parallel build for Visual Studio


Attached the diff, too

[LigH]

Well, I looked from the opposite side, pointing out it's just a nick, not a real name ... tastes are different.

[SmilingWolf]

Well, I looked from the opposite side, pointing out it's just a nick, not a real name ... tastes are different.
Sure, it's really not a big deal

64bits single-threaded binaries only (MSYS2/GCC 8.2):
VVCSoftware_VTM-2.2-156-g0326358: https://mega.nz/#!k4w3iQJI!0zN4oMEP2Pmg2hvN6ysTzxcI9yroYrhoPcxcwzJ4RP8

[SmilingWolf]

64bits single-threaded binaries only (MSYS2/GCC 8.2):
VVCSoftware_VTM-3.0rc1: https://mega.nz/#!klR2xAqI!-6CgrU7UInB6rNQUjplMiaE1g7JOhWRHNtmK38xAO6o

[Jamaika]

I will add commands for the 8bit codec. They still need to work on decoding.

EncoderApp.exe -i image_21447.yuv -b video.vvc -wdt 1920 -hgt 1080 --InputBitDepth=8 --InputChromaFormat=420 --QP=0
--SEIDecodedPictureHash=0 --Verbosity --FramesToBeEncoded=1 --ConformanceWindowMode=0 --FrameRate=25
--QuadtreeTULog2MaxSize=5 --QuadtreeTUMaxDepthIntra=4 --QuadtreeTUMaxDepthInter=4 --Profile=next
--IntraPeriod=1 --GOPSize=1 --TransformSkip=1 --TransformSkipFast=1 --SEIDecodedPictureHash=3 --QTBT=1 --CTUSize=32

DecoderApp.exe -b video.vvc -o output.yuv --SEIDecodedPictureHash=0 --OutputBitDepth=8
https://www.sendspace.com/file/7ho3k5

[SmilingWolf]

The official testing guidelines (http://phenix.it-sudparis.eu/jvet/doc_end_user/current_document.php?id=4119) actually suggest using the config files already included in the repo, so the cmdline should look more like:

bin/EncoderApp.exe -c cfg/encoder_randomaccess_vtm.cfg --InputFile=orig.i420.yuv --ReconFile=vvc.qp31.3.0rc1.yuv --BitstreamFile=vvc.qp31.3.0rc1.bin --FrameRate=24000/1001 --FramesToBeEncoded=2159 --SourceWidth=320 --SourceHeight=240 --InputBitDepth=8 --OutputBitDepth=8 --InternalBitDepth=8 --QP=31

[Jamaika]

The official testing guidelines (http://phenix.it-sudparis.eu/jvet/doc_end_user/current_document.php?id=4119) actually suggest using the config files already included in the repo, so the cmdline should look more like:

bin/EncoderApp.exe -c cfg/encoder_randomaccess_vtm.cfg --InputFile=orig.i420.yuv --ReconFile=vvc.qp31.3.0rc1.yuv --BitstreamFile=vvc.qp31.3.0rc1.bin --FrameRate=24000/1001 --FramesToBeEncoded=2159 --SourceWidth=320 --SourceHeight=240 --InputBitDepth=8 --OutputBitDepth=8 --InternalBitDepth=8 --QP=31
Thanks for info
These theoretical encoding times are really JM versus HM; encoders which are far too slow for any practical use, and really not very good psychovisually. And for decoder complexity, that's what Profiles and Levels are for. If there is a 16x worst case, probably 85% of the practical efficiency gains can be found in the first 2x of decoder complexity. Hitting the right balance between efficiency gains and decoder complexity is a huge part of designing a major bitstream format, and one of the reasons that the MPEG/ITU codecs are so good. There are just so many eyeballs from so many different industry sectors pounding on it to squeeze every last bit and MIPS out.

A little advertising. What is the difference between HEVC and VVC?

VVC Test Model 1.0 New block partitioning
• 128x128 Coding Tree Units (CTU)
• Recursive quadtree partitioning (QT)
• Nested recursive multi-type tree partitioning (MTT) with binary or ternary split

Oh, but it means more precision as well as a computer adapted to 8K movies.:confused:
Otherwise, the film is processed four times longer than JCTVC using the parameters from the official test.

[benwaggoner]

VVCSoftware_VTM-3.0-ae9412fc (https://drive.google.com/open?id=1xZQABtoaSFgGu11YstmHKYLzO3elemlC) (x64 SSE2/AVX/AVX2 MSVC 19.16.27024)
Are there release notes for these new builds somewhere?

I might take a whack at some test VVC encodes for my codec challenge (https://forum.doom9.org/showthread.php?t=175776) over the long weekend.

[Wolfberry]

https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/tags

More like a change log, but this is the only one I can find.

[LigH]

There is a new cmake-update (https://vcgit.hhi.fraunhofer.de/ksuehring/VVCSoftware_VTM/tree/cmake-update) branch to fix the lack of CMake support in MSYS2/MinGW. The project compiles now with both MinGW32 (GCC 7.3.0) and MinGW64 (GCC 8.2.0), despite some persisting BBuildEnv warnings.

Unfortunately, the created apps crash with an external exception c000001d (illegal instruction) on an AMD Phenom-II; I assume they require more than just SSE2 to run at all. Will test tomorrow on an FX CPU.
__

P.S.:

--SIMD SIMD extension to use (SCALAR, SSE41, SSE42, AVX, AVX2, AVX512), default: the highest supported extension

That explains. Enjoy parallelism.

I noticed that the MinGW32 build (GCC 7.3.0) reports [SIMD=SSE42], but the MinGW64 build (GCC 8.2.0) reports [SIMD=AVX] on an AMD FX-5600.

VVCSoftware_VTM-2.2 cmake-update 67208da2 (https://www.mediafire.com/file/c3655vcz7300l3l/VVCSoftware_VTM-2.2_cmake-update_67208da2.7z/file)

BTW, is it correct that the current VTM encoder does not even support Y4M, only raw YUV?

[Jamaika]

BTW, is it correct that the current VTM encoder does not even support Y4M, only raw YUV?
Encoder supports raw yuv and y4m, but decoder has only raw yuv.
If true then output 10-bit and 12-bit YUV data as 5-byte and 3-byte (respectively) packed YUV data. Ignored for interlaced output.

[Tommy Carrot]

BTW, is it correct that the current VTM encoder does not even support Y4M, only raw YUV?

Haven't tried VTM encoder in the last few weeks, so maybe it has been added since, but indeed, when i tested it, it only supported raw yuv. Every input parameter had to be specified manually.

Btw, thanks everybody who share builds here. I really appreciate it.

[LigH]

Input parameters should preferably be collected in configuration files. The repo offers a wide variety of examples.

I'll try a little Y4M tomorrow, thanks.

[LigH]

The cmake-update patch has been merged. Compilation with MinGW+GCC now works from the master branch.

VVCSoftware_VTM-3.0 14a70bbb (http://www.mediafire.com/file/09m66om7jnmuus1/VVCSoftware_VTM-3.0_14a70bbb.7z/file)

[LigH]

The media-autobuild_suite supports building VVC binaries now.

[FranceBB]

The media-autobuild_suite supports building VVC binaries now.

Thanks for the binary.
I wanted to play a bit with it and I know that it can open .yuv files, so I tried to open Avisynth via ffmpeg and pipe it to vvc.exe via yuv4mpegpipe, but it seems that it can't open it, 'cause it doesn't like yuv4mpeg:


ffmpeg.exe -i "\\VBOXSVR\Share_Windows_Linux\Production\AVS\test.avs" -strict -1 -an -f yuv4mpegpipe - | vvc.exe -i - --Profile=next --FrameRate=24000/1001 --InputBitDepth=8 --OutputBitDepth=8 --InternalBitDepth=8 --QP=31 --FramesToBeEncoded=21 --QuadtreeTULog2MaxSize=5 --QuadtreeTUMaxDepthIntra=4 --QuadtreeTUMaxDepthInter=4 --GOPSize=1 --IntraPeriod=1 --CTUSize=32 --BitstreamFile=vvc.bitsteam -o "\\VBOXSVR\Share_Windows_Linux\raw_video.vvc"

pause


https://i.imgur.com/55Jwu8N.png

If I try to use "--y4m -" like in x265, instead, it gives "command not found".

I then tried to use "rawvideo" as pipe, but it still says "impossible to open -".

ffmpeg.exe -i "\\VBOXSVR\Share_Windows_Linux\Production\AVS\test.avs" -strict -1 -an -f rawvideo - | vvc.exe -i - --Profile=next --FrameRate=24000/1001 --InputBitDepth=8 --OutputBitDepth=8 --InternalBitDepth=8 --QP=31 --FramesToBeEncoded=21 --QuadtreeTULog2MaxSize=5 --QuadtreeTUMaxDepthIntra=4 --QuadtreeTUMaxDepthInter=4 --GOPSize=1 --IntraPeriod=1 --CTUSize=32 --BitstreamFile=vvc.bitsteam -o "\\VBOXSVR\Share_Windows_Linux\raw_video.vvc"

pause

Am I doing something wrong with the pipe or does vvc open only uncompressed .yuv file (and not even pipe)?

[LigH]

The command line syntax of VVC is definitely different and a lot more complex than the one of x265 or even x264. And it is not compatible (and there is no reason why it should). Due to the complexity, it is recommended to use configuration files. A bunch of them are available from their source repository.

Only support for raw YUV is documented. But they may support Y4M too, I heard from other testers. Yet, I don't know whether it supports pipes or not. All configuration examples I saw referred to files. The error message "impossible to open -" suggests that it assumes "-" to be a file name, not understanding it means "read from a pipe".

[Jamaika]

Use file "yuv"
ffmpeg.exe -y -loglevel error -i Untitled.mp4 -an -f yuv4mpegpipe -frames 1 -vf scale=1920:1080:in_color_matrix=bt709:in_range=limited:out_color_matrix=bt709:out_range=limited,format=yuv420p 111.yuv |
vvc.exe -i 111.yuv -b video.vvc -wdt 1920 -hgt 1080 --FrameRate=25000/1000 --InputBitDepth=8 --InputChromaFormat=420 --QP=0 --Profile=next
--QuadtreeTULog2MaxSize=5 --QuadtreeTUMaxDepthIntra=4 --QuadtreeTUMaxDepthInter=4 --IntraPeriod=1 --DecodingRefreshType=1 --GOPSize=1 --FramesToBeEncoded=1
--ConformanceWindowMode=0 --SEIDecodedPictureHash=3 --CTUSize=32
The parameters in red must be entered.:cool:

[FranceBB]

Just tested it; it works. Thanks ^_^

[hajj_3]

VVC Test Model v3.2 has been released: https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM

Hopefully some of you guys will do some new compression comparisons to h265, vp9, x264 and av1.

changelog: https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/tags

[FranceBB]

VVC Test Model v3.2 has been released: https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM


Oh, that's interesting.


Hopefully some of you guys will do some new compression comparisons to h265, vp9, x264 and av1.

changelog: https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/tags


I will indeed as I have an 8K 4:2:0 SDR footage at 60fps progressive.
LigH, can you compile the new version?

[benwaggoner]

I will indeed as I have an 8K 4:2:0 SDR footage at 60fps progressive.

I am profoundly curious to hear how long it takes to encode that!

Previous test models for VVC were quite a bit faster than AV1, at least. But 8K...

It would be interesting to compare 8K HEVC v. VVC. I've heard suggestions that both EVC and VVC will have higher relative gains to HEVC at 8K.

[LigH]

VVCSoftware VTM-4.0rc1 4add4da (https://www.mediafire.com/file/60eaerzwwu3ngdz/VVCSoftware_VTM-4.0rc1_4add4da.7z/file) (MSYS2, MinGW32 + GCC 7.4.0 / MinGW64 + GCC 8.2.1)

[Tommy Carrot]

Thanks for the new builds. The quality/efficiency is improving steadily with each major version. The encoding speed is getting slower and slower, but that's to be expected as they add more tools into the encoder. Now it's around 3 times slower than the slowest preset of aomenc.

[EwoutH]

VTM-4.0.1 (https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/tags/VTM-4.0.1) is released

Changes

Fix tickets #153, #183, #185, #188, #190, #191, #193, #194, #195, #196, #197, #199, #200
Add JVET-M0277 on PCM and loop filter
Add JVET-M0428 on deblocking optimization
Add JVET-M0451 on interop syntax
Add JVET-M0600 on rate control
Add encoder speedup for JVET-M0102 (ISP)
Add macro to disable MMVD
Other minor improvements


Windows builds

Version 4.0.1 (https://ci.appveyor.com/project/EwoutH/vvcsoftware-vtm/builds/22666466/artifacts).
Master branch (https://ci.appveyor.com/project/EwoutH/vvcsoftware-vtm/build/artifacts).

[LigH]

New upload: VVCSoftware VTM-4.0.1 ccf7079 (https://www.mediafire.com/file/zxxc9kel9bnjlod/VVCSoftware_VTM-4.0.1_ccf7079.7z/file) (MSYS2, MinGW32 + GCC 7.4.0 / MinGW64 + GCC 8.3.0)

[FranceBB]

I tried to encode an 8K 12bit video on my Windows Server 2019, but it outputs:

Error: The internalBitDepth must not be greater than the bitDepthConstraint value

Which basically means that the profile I'm trying to use doesn't support such an high bit-depth.
Is there a 12bit profile that I can use or do I have to encode at 8bit/10bit only?
I ended up encoding at 10bit with a few tests, like:

ffmpeg.exe -i "\\VBOXSVR\Share_Windows_Linux\Production\AVS\test2.avs" -strict -1 -an -f yuv4mpegpipe -vf scale=7680:4320:in_color_matrix=bt709:in_range=limited:out_color_matrix=bt709:out_range=limited,format=yuv444p 111.yuv | vcc.exe -i 111.yuv -b "raw_video.vvc" -wdt 7680 -hgt 4320 --Profile=next --FrameRate=60000/1001 --InputBitDepth=12 --OutputBitDepth=10 --InternalBitDepth=10 --InputChromaFormat=444 --QP=8 --FramesToBeEncoded=5220 --GOPSize=1 --IntraPeriod=1 --ConformanceWindowMode=0 --SEIDecodedPictureHash=3 --CTUSize=32 --BitstreamFile=vvc.bitsteam

pause

Which parameters do I have to set to set Reframe equal to 4?
I tried with --GOPSize=2 --IntraPeriod=4 as Intra must be a multiple of the GOPSize, but it fails to encode.
Also --GOPSize=4 --IntraPeriod=-1 fails to encode.
If I manage to get it right, I'll share the encode at different --QP. The only bad thing is that it takes minutes (yes, minutes) to encode even a single frame on my home system and it's a faster (but still slow as hell) on my work machine. What speed do you usually get on your systems?


Last but not least, in case anyone needs this to encode SD/HD/FULL HD 8bit contents, here is VVCSoftware_VTM_V4.1.0 (Encoder and Decoder) for Windows XP x86: Link (https://mega.nz/#!LAcERQCS!4816EPYTcKKPxy-K9lu2xyQJumJ_b4oIF1Ncs6_Eypg)

Working example (Image): Link (https://i.imgur.com/Krjtya7.png)

The reason why I specified the resolution and the bit depth is only 'cause above FULL HD you'll end up using too much RAM and it's gonna crash. (Not that everyone wants to encode an 4K/8K on such a system).

[Jamaika]

Hi FranceBB
Profile NEXT is the successor of only profile MAIN.
Profile MAIN is only 8bit and has chroma format of 420.
As you added 10 bitdepth the encoder automatically changed to the profile MAIN10, which has nothing to do with the VVC codec. At least this is recommended in the .cfg settings.
Of course you can change the parameters so that the encoder changes for the 12 bitdepth profile settings to MAINREXT.
m_bitDepthConstraint = ( ( m_profile == Profile::MAINREXT || m_profile == Profile::NEXT ) ? 16 : 8 );

[benwaggoner]

Hi FranceBB
Profile NEXT is the successor of only profile MAIN.
Profile MAIN is only 8bit and has chroma format of 420.
Nooo! We can't have ANOTHER generation of codecs that have a default profile that's 8-bit only. We are entering the HDR era, and 10-bit really need to be the baseline for everything.

[nevcairiel]

Nooo! We can't have ANOTHER generation of codecs that have a default profile that's 8-bit only. We are entering the HDR era, and 10-bit really need to be the baseline for everything.

There should always be different profiles for 8-bit and 10-bit. The difference is only how you word the spec to make supporting both "main" profiles mandatory at the same time. HEVC already did a pretty good job at that, and 10-bit decoders are pretty wide-spread.
What is a "default profile" beyond an implementation detail, anyway?

Even if you shove both into one profile, if someone really wants to, they'll still make a 8-bit only decoder. So lets at least have the clarity we need and call them different.

[benwaggoner]

There should always be different profiles for 8-bit and 10-bit. The difference is only how you word the spec to make supporting both "main" profiles mandatory at the same time. HEVC already did a pretty good job at that, and 10-bit decoders are pretty wide-spread.
What is a "default profile" beyond an implementation detail, anyway?

Even if you shove both into one profile, if someone really wants to, they'll still make a 8-bit only decoder. So lets at least have the clarity we need and call them different.
Good point. 8-bit SDR content should be encoded at 8-bit. It's more about setting the standard that 10-bit should always be decodable.

[FranceBB]

Hi FranceBB
Profile NEXT is the successor of only profile MAIN.
Profile MAIN is only 8bit and has chroma format of 420.
As you added 10 bitdepth the encoder automatically changed to the profile MAIN10, which has nothing to do with the VVC codec. At least this is recommended in the .cfg settings.
Of course you can change the parameters so that the encoder changes for the 12 bitdepth profile settings to MAINREXT.
m_bitDepthConstraint = ( ( m_profile == Profile::MAINREXT || m_profile == Profile::NEXT ) ? 16 : 8 );

Oh, ok, I got it. When I have time, I'm gonna try to make a few tests and I'm gonna be back here with the results. I was thinking about running some ssim/psnr tests, but since there are no decoders available to natively read it, I would have to re-encode it to a lossless format and then run ssim/psnr; the only problem is that I have no idea how to do that. Is there something to actually re-encode a VVC file? Otherwise I think I'm just gonna use my eyeballs.

[Jamaika]

:logfile:I created VVC ver.4.2 8-12bit codec only for color sample 420 with the profile NEXT associated with profile MAINREXT. Of course, there is no specification for VVC.
The second one is currently a codec toy. You need to add the appropriate parameters to each frame of the movie. A very burdensome function `--frameX="..."`
Errors codec for movies than 8bit. Can not be used yuv4mpegpipe
ffmpeg.exe -y -loglevel error -i "video.mp4" -an -f rawvideo -frames 16
-vf scale=1280:720:in_color_matrix=bt709:in_range=limited:out_color_matrix=bt709:out_range=limited,format=yuv420p12le -strict -1 111.yuv
EncoderApp.exe --SummaryVerboseness -c "encoder_randomaccess_vtm.cfg" --InputFile=111.yuv --BitstreamFile=video.vvc --SourceWidth=1280 --SourceHeight=720 --FrameRate=25 --ReshapeSignalType=1
--InputBitDepth=12 --InternalBitDepth=12 --OutputBitDepth=12 --MSBExtendedBitDepth=12 --InputChromaFormat=420 --ChromaFormatIDC=420 --ConformanceWindowMode=0 --FramesToBeEncoded=16

Delete InternalBitDepth in files cfg.
DecoderApp.exe -b video.vvc -d 12 --SEIDecodedPictureHash=0 -o 112.yuv

ffplay.exe -pixel_format yuv420p12le -video_size 1280x720 112.yuv


We are entering the HDR era, and 10-bit really need to be the baseline for everything.
Maybe. For a VVC codec it isn't a significant SDR or HDR. It doesn't distinguish between bitdepth. This is just an info function ReshapeSignalType

https://www.sendspace.com/filegroup/wLdEiS69ylKrR13h57SViQ

[LigH]

The media-autobuild suite enabled compiling with split parallelism.

[Jamaika]

JVET-N0671: Support of 4:4:4 and 4:2:2 chroma formats in VVC (https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/merge_requests/443)

[Jamaika]

The media-autobuild suite enabled compiling with split parallelism.

I didn't succeed. Under Windows doesn't work with gcc.
OpenMP software needs assembler, although creators sometimes add in cmake. :(
https://github.com/jb-alvarado/media-autobuild_suite/commit/ad85b55ad6639aaf8e96e20198c62f5831737dd5

[LigH]

Would you report that as issue there (https://github.com/jb-alvarado/media-autobuild_suite/issues)? I don't know what it lacks exactly. NASM is available in MABS.

[Jamaika]

I don't know how to compile z_Windows_NT-586_asm.asm. Without this I can't close the file object in gcc. I suppose you can do it, but I don't know how.
https://github.com/llvm-mirror/openmp

[LigH]

I wonder what happens for you ... MABS could compile the 32 bit version of VVC for me. But I got stuck in another faulty project, and I hate disabling many other tools just to get one compiled. I will test it soon™ ...

[Jamaika]

What do you mean? Bugs in the VVC project.
I had to add everywhere for GCC 9.0.1:
(MsgLevel) ERROR,
correct include:
#include "CommonLib/CacheModel.h" in DecLib.h
#include "CommonLib/MCTS.h" in EncCu.cpp
#include "Utilities/program_options_lite.h" in decmain.cpp
for( int ctuTsAddr = startCtuTsAddr; ctuTsAddr < boundingCtuTsAddr; ctuTsAddr += pcPic->cs->pcv->widthInCtus )
encodeCtus( pcPic, bCompressEntireSlice, bFastDeltaQP, ctuTsAddr, ctuTsAddr + pcPic->cs->pcv->widthInCtus, m_pcLib );
CHECK(cs.sps == 0, "No SPS present");
writeBlockStatisticsHeader(cs.sps); in EncSlice.cpp
#if ENABLE_WPP_PARALLELISM
// static
#endif in EncSlice.h
Add video 12bit
in VLCReader.cpp
ptl->setBitDepthConstraint( ( ptl->getProfileIdc() == Profile::MAINREXT || ptl->getProfileIdc() == Profile::NEXT ) ? 12 : 8 );
in EncAppCfg.cpp
("InputBitDepth", m_inputBitDepth[CHANNEL_TYPE_LUMA], 0, "Bit-depth of input file")
m_bitDepthConstraint = ( ( m_profile == Profile::MAINREXT || m_profile == Profile::NEXT ) ? 12 : 8 );
xConfirmPara(m_bitDepthConstraint!=((m_profile==Profile::MAINREXT || m_profile==Profile::NEXT)?12:8), "BitDepthConstraint must be 8 for NEXT profile and 12 for MAINREXT profile.");

PS Of course I added mingw.mutex.h and delete SIMD, but you probably will not have to.
/* std::string SIMD;
df::program_options_lite::Options optsSimd;
optsSimd.addOptions()( "SIMD", SIMD, string( "" ), "" );
df::program_options_lite::SilentReporter err;
df::program_options_lite::scanArgv( optsSimd, argc, ( const char** ) argv, err );*/
fprintf( stdout, "[SIMD=NONE] "/*, read_x86_extension( SIMD )*/ );
// case AVX512/AVX2/AVX/SSE42/SSE41:
// _init...X86<AVX512/AVX2/AVX/SSE42/SSE41>(...);
// break; in InitX86.cpp

[LigH]

I hope we talk about the same topic... by "another faulty project", I meant anything else compiled by MABS. In this case, rav1e and vulkan. Not VVC.

The media-autobuild suite enabled compiling with split parallelism.

I didn't succeed. Under Windows doesn't work with gcc.

It just compiled well in the media-autobuild_suite. But there is no GCC 9, and there are no additional patches to enable 12 bit depth (the help output reports supporting --Profile main-RExt though), just plain git HEAD.

VVCSoftware: VTM Encoder Version 4.2 [Windows][GCC 7.4.0][32 bit] [SIMD=SSE42] [SPLIT_PARALLEL (6 jobs)][OMP: WAIT_POLICY=,THREAD_LIMIT=]
VVCSoftware: VTM Encoder Version 4.2 [Windows][GCC 8.3.0][64 bit] [SIMD=AVX] [SPLIT_PARALLEL (6 jobs)][OMP: WAIT_POLICY=,THREAD_LIMIT=]

VVCSoftware VTM-4.2 02d258f4 (https://www.mediafire.com/file/te9hwccr53z5cu4/VVCSoftware_VTM-4.2_02d258f4.7z/file)

[foxyshadis]

It just compiled well in the media-autobuild_suite. But there is no GCC 9

GCC 9.0.1 was tagged at the beginning of February, they've started the release-candidate cycle toward the 9.1 release, which is supposed to be within a week or two. Presumably it's pretty stable at this point, though I'd definitely compare any issues to 8.3 as well.

[Jamaika]

I understand that there is an open secret. I know that there is an MSYS2 compiler. He contains components in this GCC 8.3, but with GCC 9.0 doesn't work anymore and contains something to assembler. This thing is a secret.
The second thing. If added the function split paralleism why was the function wpp paralleism not added? Are they interchangeable? I see that both functions can be added in the project.
GCC 9.0.1 was tagged at the beginning of February, they've started the release-candidate cycle toward the 9.1 release, which is supposed to be within a week or two. Presumably it's pretty stable at this point, though I'd definitely compare any issues to 8.3 as well.
There is always something to be improved in every project. With gcc 9.x, I have a problem with <ctime>. In dependence on the version of gcc, once in the files you have to add and once not. Something is instability.

[LigH]

The MSYS2 environment may be a bit conservative, regarding provided packages, but usually quite well groomed. I will leave the "bleeding edge technology" to other people and keep using a toolset I can usually handle with little efforts. And in most cases, the result was reliable.

[Wolfberry]

The second thing. If added the function split paralleism why was the function wpp paralleism not added? Are they interchangeable? I see that both functions can be added in the project.

VVCSoftware_VTM !390 (https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/merge_requests/390)

VTM fails to build when WPP_PARALLELISM is enabled as of now.

[Jamaika]

Interesting. I have compiled EncCu on me, but don't have assembler.:D

[LigH]

My recent vvc-git/build-64bit/ab-suite.build.log (https://pastebin.com/wuX3kwgK) only reports "Building CXX object" ...

[Jamaika]

New version 5.0rc1
VVCSoftware: VTM Encoder Version 5.0rc1 [Windows][GCC 9.0.1][64 bit] [SIMD=NONE] [ENABLE_TRACING] [SPLIT_PARALLEL (6 jobs)][WPP_PARALLEL][OMP: WAIT_POLICY=,THREAD_LIMIT=]
https://www.sendspace.com/file/gydtlw

#define JVET_N0415_CTB_ALF 1 // JVET-N0415: CTB-based ALF switch
#define JVET_N0105_LFNST_CTX_MODELLING 1 // LFNST index signalled without intra mode dependency and with on ctx-coded bin
#define JVET_N0193_LFNST 1 //Low Frequency Non-Separable Transform (LFNST), previously, Reduced Secondary Transform (RST)
#define JVET_N0217_MATRIX_INTRAPRED 1 // matrix-based intra prediction (MIP)
#define JVET_N0400_SIGNAL_TRIANGLE_CAND_NUM 1 // JVET-N0400, JVET-N0447, JVET-N0500, JVET-N0851, align triangle merge candidate number and regular merge candidate number
#define JVET_N0413_RDPCM 1 // Residual DPCM JVET-N0413/N0214
#define JVET_N0866_UNIF_TRFM_SEL_IMPL_MTS_ISP 1 // JVET-N0866: unified transform derivation for ISP and implicit MTS (combining JVET-N0172, JVET-N0375, JVET-N0419 and JVET-N0420)
#define JVET_N0340_TRI_MERGE_CAND 1
#define JVET_N0302_SIMPLFIED_CIIP 1
#define JVET_N0327_MERGE_BIT_CALC_FIX 1
#define JVET_N0324_REGULAR_MRG_FLAG 1
#define JVET_N0251_ITEM4_IBC_LOCAL_SEARCH_RANGE 1
#define JVET_N0435_WAIP_HARMONIZATION 1
#define JVET_N0168_AMVR_ME_MODIFICATION 1 // Correct the cost and bits calculation in encoder side
#define JVET_N0068_AFFINE_MEM_BW 1 // memory bandwidth reduction for affine mode
#define JVET_N0308_MAX_CU_SIZE_FOR_ISP 1
#define JVET_N0280_RESIDUAL_CODING_TS 1
#define JVET_N0103_CGSIZE_HARMONIZATION 1 // Chroma CG sizes aligned to luma CG sizes
#define JVET_N0146_DMVR_BDOF_CONDITION 1 // JVET-N146/N0162/N0442/N0153/N0262/N0440/N0086 applicable condition of DMVR and BDOF
#define JVET_N0470_SMVD_FIX 1 // remove mvd_l1_zero_flag condition, align to spec text.
#define JVET_N0235_SMVD_SPS 1
#define JVET_N0671 1
#if JVET_N0671
#define JVET_N0671_CHROMA_FORMAT_422 1
#define JVET_N0671_RGB 1
#define JVET_N0671_CCLM 1
#define JVET_N0671_AFFINE 1
#define JVET_N0671_DMVR 1
#define JVET_N0671_RDCOST_FIX 1
#define JVET_N0671_INTRA_TPM_ALIGNWITH420 1
#endif //JVET_N0671
#define JVET_N0843_BVP_SIMPLIFICATION 1
#define JVET_N0448_N0380 1 // When MaxNumMergeCand is 1, MMVD_BASE_MV_NUM is inferred to be 1.
#define JVET_N0266_SMALL_BLOCKS 1 // remove 4x4 uni-pred, 4x8/8x4 bi-pred from regular inter modes
#define JVET_N0054_JOINT_CHROMA 1 // Joint chroma residual coding mode
#define JVET_N0317_ADD_ZERO_BV 1
#define JVET_N0318_N0467_IBC_SIZE 1 // IBC flag dependent on CU size and disabling 128x128 IBC mode
#define JVET_N0462_FIX_CTX_MODELING 1 // Fix context modeling of inter_pred_idc
#define JVET_N0175_N0251_N0384_IBC_SMALL_CTU 1 // IBC search range arrangement for small CTU sizes
#define JVET_N0127_MMVD_SPS_FLAG 1
#define JVET_N0286_SIMPLIFIED_GBI_IDX 1 // Simplified coding of the GBi index
#define JVET_N600_AMVR_TPM_CTX_REDUCTION 1
#define JVET_N0188_UNIFY_RICEPARA 1
#define JVET_N0334_MVCLIPPING 1 // prevention of MV stroage overflow and alignment with spec of MV/CPMV modular for AMVP mode
#define JVET_N0481_BCW_CONSTRUCTED_AFFINE 1
#define JVET_N0483_DISABLE_SBT_FOR_TPM 1
#define JVET_N0180_ALF_LINE_BUFFER_REDUCTION 1 // Line buffer reduction for ALF using symmetric padding
#define JVET_N0242_NON_LINEAR_ALF 1 // enable CE5-3.2, Non-linear ALF based on clipping function
#define JVET_N0329_IBC_SEARCH_IMP 1 // IBC encoder-side improvement
#define JVET_N0325_BDOF 1 // unified right-shifts for BDOF derivation
#define JVET_N0247_HASH_IMPROVE 1 // Improve hash motion estimation
#define JVET_N0449_MMVD_SIMP 1 // Configurable number of mmvd distance entries used
#define JVET_N0363_INTRA_COST_MOD 1 // Modified cost criterion for intra encoder search
#define JVET_N0137_DUALTREE_CHROMA_SIZE 1
#define JVET_N0335_N0085_MV_ROUNDING 1 // MV rounding unification
#define JVET_N0332_LTRP_MMVD_FIX 1 // MMVD scaling considering LTRPs from N0332
#define JVET_N0477_LMCS_CLEANUP 1
#define JVET_N0220_LMCS_SIMPLIFICATION 1
#define JVET_N0185_UNIFIED_MPM 1
#define JVET_N0271_SIMPLFIED_CCLM 1 // Simplified CCLM parameter derivation in JVET-N0271
#define JVET_N0178_IMPLICIT_BDOF_SPLIT 1
#define JVET_N0383_N0251_IBC_COL_VPDU_REMOVE 1
#define JVET_N0407_DMVR_CU_SIZE_RESTRICTION 1 // Disable 4xN/8x8 CUs for DMVR
#define JVET_N0196_SIX_TAP_FILTERS 1 // 6-tap filters for affine motion compensation
#define JVET_N0213_TMVP_REMOVAL 1 // Remove TMVP candidates from merge and amvp mode with samples <= 32
#define JVET_N0492_NO_HIERARCH_CBF 1 // Allow CBFs writing for leaf TU only
#define JVET_N0473_DEBLOCK_INTERNAL_TRANSFORM_BOUNDARIES 1 // JVET-N0473, JVET-N0098: Deblocking of ISP/SBT TU boundaries
#define INCLUDE_ISP_CFG_FLAG 1
#define JVET_N0246_MODIFIED_QUANTSCALES 1

delete
#define HEVC_TILES_WPP 1
#define JVET_MMVD_OFF_MACRO 0

[Jamaika]

Short test additional function for yuv420p 8bit QP=32 CTU=32 LCTUFast=0 with encoder_randomaccess_vtm.cfg
no function = effect blur
add full paralleism = much smaller effect blur only frame I
add tracing = test encoder, longer total time
add rext = much smaller effect blur only frame I
add rext + paralleism = effect banding
add only split paralleism = file is the same as no function

Conclusions:
LCTUFast should be enabled for small CTUs. The frames have more details.

[EwoutH]

vvc2 -i "E:\Morocco8K-8b-444.yuv" -b vvc-test.vvc -wdt 1920 -hgt 1080 -fr 60 --InputBitDepth=8 --InputChromaFormat=444

VVCSoftware: VTM Encoder Version 5.0rc1 [Windows][GCC 9.0.1][64 bit] [SIMD=AVX2] [ENABLE_TRACING] [SPLIT_PARALLEL (6 jobs)][WPP_PARALLEL][OMP: WAIT_POLICY=,THREAD_LIMIT=]

terminate called after throwing an instance of 'Exception'
what():
ERROR: In function "xCheckParameter" in EncAppCfg.cpp:1979: Next profile with an alternative partitioner has to be enabled if HEVC_USE_RQT is off!

I got the following error, any idea how I can fix this?

[Jamaika]

Add more commands, e.g. :)
https://www.sendspace.com/file/ki5wkj
VVCSoftware: VTM Encoder Version 5.0rc1 [Windows][GCC 9.1.1][64 bit] [SPLIT_PARALLEL (6 jobs)][WPP_PARALLEL][OMP: WAIT_POLICY=,THREAD_LIMIT=]

TOOL CFG: IBD:0 HAD:1 RDQ:1 RDQTS:1 RDpenalty:0 LQP:0 SQP:0 ASR:1 MinSearchWindow:96 RestrictMESampling:0 FEN:1 ECU:0 FDM:1 CFM:0 ESD:0 TransformSkip:1 TransformSkipFast:1 TransformSkipLog2MaxSize:5 Slice: M=0 Tiles:1x1 MCTS:0 CIP:0 SAO:0 ALF:1 PCM:0 TransQuantBypassEnabled:0 WPP:0 WPB:0 PME:2 WaveFrontSynchro:0 WaveFrontSubstreams:1TMVPMode:1 DQ:1 SignBitHidingFlag:0 RecalQP:0
NEXT TOOL CFG: LFNST:1 MMVD:1 Affine:1 AffineType:1 SubPuMvp:1+0 DualITree:1 IMV:1 BIO:1 LMChroma:1 CclmCollocatedChroma:0 MTS: 1(intra) 0(inter) SBT:1 ISP:1 SMVD:1 CompositeLTReference:0 GBi:1 GBiFast:1 LADF:0 MHIntra:1 Triangle:1 AllowDisFracMMVD:1 AffineAmvr:1 AffineAmvrEncOpt:1 DMVR:1 MmvdDisNum:6 RDPCM:0 IBC:0 HashME:0 WrapAround:0 Reshape:1 (Sigal:HDR-PQ ) MIP:1 EncDbOpt:0
FAST TOOL CFG: LCTUFast:1 FastMrg:1 PBIntraFast:1 IMV4PelFast:1 MTSMaxCand: 3(intra) 4(inter) ISPFast:1 FastLFNST:0 AMaxBT:1 E0023FastEnc:1 ContentBasedFastQtbt:0 UseNonLinearALFLuma:1 UseNonLinearALFChroma:1 FastMIP:0 NumSplitThreads:1 NumWppThreads:1+0 EnsureWppBitEqual:1


started @ Tue May 07 02:17:04 2019
*** SPS numBytesInNALunit: 67
*** PPS numBytesInNALunit: 10
*** APS numBytesInNALunit: 45
*** IDR_W_RADL numBytesInNALunit: 2889
POC 0 TId: 0 ( I-SLICE, QP 29 ) 24200 bits [Y 54.4181 dB U 62.1299 dB V 999.9900 dB] [WY 54.2387 dB WU 65.1402 dB WV 999.9900 dB] [ET 26 ] [L0 ] [L1 ]

[EwoutH]

VVC VTM 5.0 (https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/tags/VTM-5.0) is released!

Can someone confirm if these AppVeyor builds (https://ci.appveyor.com/project/EwoutH/vvcsoftware-vtm) are functioning? --help functions correctly, but I can't get it to encode anything.

[Pushman]

VVC VTM 5.0 (https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/tags/VTM-5.0) is released!

Can someone confirm if these AppVeyor builds (https://ci.appveyor.com/project/EwoutH/vvcsoftware-vtm) are functioning? --help functions correctly, but I can't get it to encode anything.

You need this file:
https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/blob/master/cfg/encoder_randomaccess_vtm.cfg

[EwoutH]

You need this file:
https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/blob/master/cfg/encoder_randomaccess_vtm.cfg

Thanks, got it working!

vvc -i "E:\Morocco8K-8b-444.yuv" -b vvc-test.vvc -wdt 1920 -hgt 1080 -fr 60 --InputBitDepth=8 --InputChromaFormat=444 -f 60 -c cfg_encoder_randomaccess_vtm.cfg

After 23 minutes 25 frames encoded. Even aom-av1 is fast compared against this :P.

Also: Huge MR ahead: JVET-N0857: slices/tiles/bricks (https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/merge_requests/544)

[EwoutH]

Special Windows build for JVET-N0857: slices/tiles/bricks (https://ci.appveyor.com/project/EwoutH/vvcsoftware-vtm/builds/24430873/artifacts)

Edit 15-05: Updated build (https://ci.appveyor.com/project/EwoutH/vvcsoftware-vtm/builds/24555900/artifacts)

[benwaggoner]

Special Windows build for JVET-N0857: slices/tiles/bricks (https://ci.appveyor.com/project/EwoutH/vvcsoftware-vtm/builds/24430873/artifacts)
Does anyone have a good breakdown of the impact of bricks?

[EwoutH]

JVET-N0857: slices/tiles/bricks (https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/merge_requests/544) is merged!

[soresu]

Bricks are a new one to me, or is this just a slight variant on the tile technique?

[iwod]

So nothing new came out of the MC-IF meeting?

https://www.mc-if.org/mc-if-meeting-and-outreach

[iwod]

There is a new article from BBC R&D

https://www.bbc.co.uk/rd/blog/2019-05-av1-codec-streaming-processing-hevc-vvc

I can't find any reference but I assume they tested it with VTM 5.0.

Results looks, good especially for single pass and Streaming. I Still wish VVC will push further in bitrate reduction. For resolution I cared about, which is NOT 4K / UHD, I think the reduction was only 25%.

[Jamaika]

Lot of advertising, zero effect playback.
https://www.5kplayer.com/video-music-player/vvc-video-codec-download-free.htm

[benwaggoner]

There is a new article from BBC R&D

https://www.bbc.co.uk/rd/blog/2019-05-av1-codec-streaming-processing-hevc-vvc

I can find any reference but I assume they tested it with VTM 5.0.

Results looks, good especially for single pass and Streaming. I Still wish VVC will push further in bitrate reduction. For resolution I cared about, which is NOT 4K / UHD, I think the reduction was only 25%.
Nrr, another mean PSNR study, no subjective quality analysis. PNSR is the least well subjectively correlated metric we ever use.

Also, past studies have shown that libaom shows better PSNR but similar or slightly worse subjective quality than HEVC HM. A study that had PSNR and subjective data would let us see if AV1 is getting psychovisual improvements. The hope is libaom would be evolving to improve psychovisual quality even if it reduces PSNR.

[Jamaika]

- new fixes for codec VVC 5.0 2019.06.01

#define JVET_N0063_VUI 1 // JVET-N0063: Video Usability Information
#define JVET_N0847_SCALING_LISTS 1 //1: default mode, 2: user defined mode
#define JVET_N0438_LOOP_FILTER_DISABLED_ACROSS_VIR_BOUND 1 // loop filter disabled across virtual boundaries
#define JVET_N0067_NAL_Unit_Header 1 // NAL Unit Header
#define JVET_N0349_DPS 1 // Decoding Parameter Set
#define JVET_N0857_TILES_BRICKS 1 // VTM-5 basic Slices/Tiles/Bricks design, rectangular slices not supported yet
#define JVET_N0124_PROPOSAL1&2 1 // JVET-N0124 Proposal 1 & 2
#define JVET_N0150_ONE_CTU_DELAY_WPP 1 // one CTU delay WPP
#define EMULATION_PREVENTION_FIX 1 // fix for start code emulation reported in #270. Diverges from specification text
delete #define HEVC_DEPENDENT_SLICES 1
https://www.sendspace.com/file/zce506

[Jamaika]

- new fixes for codec VVC 5.0 2019.06.27
#define JVET_N0047_Merge_IDR_Non_IDR 1 // merging IDR and non-IDR pictures
#define JVET_N0276_CONSTRAINT_FLAGS 1 // JVET-N0276: On interoperability point signalling
#define JVET_N0278_HLS 1 // JVET-N0278: HLS for MPEG requirements on immersive media delivery and access
#define JVET_N0805_APS_LMCS 1 // JVET-N0805: Reference to APS from slice header for LMCS
#define JVET_N0070_WRAPAROUND 1 // reference wraparound simplifications
#define JVET_N0063_VUI 1 // JVET-N0063: Video Usability Information
#define JVET_N0847_SCALING_LISTS 1 //1: default mode, 2: user defined mode
#define JVET_N0438_LOOP_FILTER_DISABLED_ACROSS_VIR_BOUND 1 // loop filter disabled across virtual boundaries
#define JVET_N0067_NAL_Unit_Header 1 // NAL Unit Header
#define JVET_N0349_DPS 1 // Decoding Parameter Set
#define JVET_N0857_TILES_BRICKS 1 // VTM-5 basic Slices/Tiles/Bricks design, rectangular slices not supported yet
#define JVET_N0857_RECT_SLICES 1 // Support for rectangular slices and raster-scan slices (i.e., multiple tiles/brick in a slice)
#define JVET_N0150_ONE_CTU_DELAY_WPP 1 // one CTU delay WPP
#define JVET_M0128 1 // Implementation of RPL as in JVET-M0128
#define EMULATION_PREVENTION_FIX 1 // fix for start code emulation reported in #270. Diverges from specification text

Delete old function HEVC:
delete #define HEVC_USE_DC_PREDFILTERING
delete #define HEVC_USE_HOR_VER_PREDFILTERING
delete #define HEVC_DEPENDENT_SLICES
https://www.sendspace.com/file/live4q

[IgorC]

Subjective tests between VVC and HEVC
http://phenix.it-sudparis.eu/jvet/doc_end_user/documents/15_Gothenburg/wg11/JVET-O0451-v1.zip

[birdie]

Subjective tests between VVC and HEVC
http://phenix.it-sudparis.eu/jvet/doc_end_user/documents/15_Gothenburg/wg11/JVET-O0451-v1.zip

I've converted it to PDF:

https://www.scribd.com/document/416562888/JVET-O0451

You can also get it from here (https://www.pdfhost.net/index.php?Action=Download&File=f9894e9ab91d734abe544a6f8cc81efe).

[iwod]

So around 35% to 40% reduction.

Are there any similar test done for EVG?

[MoSal]

Is the Sedof sequence available somewhere?

[Jamaika]

New VVC codec v5.2
https://www.sendspace.com/file/uianz2
delete HEVC_TOOLS

[Jamaika]

New Viable Video Codecs on the Way? Maybe (http://www.dtcreports.com/weeklyriff/2019/06/19/new-viable-video-codecs-on-the-way-maybe/)

VVC isn’t far enough along in its development to properly assess its practicality as a next-generation MPEG codec. One of its developers, Fraunhofer, says the technology has gained 30-35 percent improved efficiency over HEVC with an eventual target of 50 percent. A finalized standard is due sometime in 2020. On the licensing side, observers say VVC will not be free, but anything beyond this eventuality is pure guesswork.

There are some caveats cloud MPEG-5/EVC, however:
1.EVC will not deliver as much efficiency over HEVC as VVC promises.
2.What IP will be used and what royalty rates for the EVC main profile will be are not known.
3.MPEG-VCEG (Video Coding Experts Group) is working with VVC, not EVC.

New VVC codec v5.2 27.07.2019
#define JVET_O1136_TS_BDPCM_SIGNALLING 1 // JVET-O1136: Unified syntax for JVET-O0165/O0200/O0783 on TS and BDPCM signalling
#define JVET_O0219_LFNST_TRANSFORM_SET_FOR_LMCMODE 1
#define JVET_O0426_MRL_REF_SAMPLES_DC_MODE 1 // JVET-O0426: align MRL reference samples used for DC intra mode prediction
#define JVET_O0366_AFFINE_BCW 1 // JVET-O0366: Simplifications on BCW index derivation process
#define JVET_O1168_CU_CHROMA_QP_OFFSET 1 // JVET-O1168: cu chroma QP offset
#define JVET_O0368_LFNST_WITH_DCT2_ONLY 1 // JVET-O0368/O0292/O0521/O0466: disable LFNST for non-DCT2 MTS candidates normatively
#define JVET_O0106_ISP_4xN_PREDREG_FOR_1xN_2xN 1 // JVET-O0106: use 4xN prediction regions for 1xN and 2xN subblocks
#define JVET_O0500_SEP_CTX_AFFINE_SUBBLOCK_MRG 1 // JVET-O0500: Different ctx models for inter affine flag and subblock merge flag
#define JVET_O0414_SMVD_LTRP 1 // JVET-O0414: long-term reference picture restriction for SMVD
#define JVET_O0258_REMOVE_CHROMA_IBC_FOR_DUALTREE 1 // JVET-O0258 Remove chroma IBC when dualtree is used
#define JVET_O1161_IBC_MAX_SIZE 1 // Limit largest IBC luma CU size to 64x64 per discussion of JVET-O1161
#define JVET_O0315_RDPCM_INTRAMODE_ALIGN 1 // JVET-O0200/O0205/O0296/O0342/O0463/O0542: Intra prediction mode alignment for BDPCM
#define JVET_O0284_CONDITION_SMVD_MVDL1ZEROFLAG 1 // JVET-O0284: condition sym_mvd_flag on mvd_l1_zero_flag
#define JVET_O0122_TS_SIGN_LEVEL 1 // JVET-O0122: Sign context and level mapping of TS residual coding.
#define JVET_O0438_SPS_AFFINE_AMVR_FLAG 1 // JVET-O0438: affine AMVR control flag conditioned on affine control flag in SPS
#define JVET_O0065_CABAC_INIT 0 // JVET-O0065: CABAC initialization
#define JVET_O0052_TU_LEVEL_CTX_CODED_BIN_CONSTRAINT 1 // JVET-O0052 Method-1: TU-level context coded bin constraint
#define JVET_O0105_ICT 1 // JVET-O0105: inter-chroma transform (ICT) as extension of joint chroma coding (JCC)
#define JVET_O0543_ICT_ICU_ONLY 1 // JVET-O0543: ICT only in Intra CUs (was Intra slices, modified during adoption)
#define JVET_N0288_PROPOSAL1 1 // JVET-N0288 Proposal 1
#define JVET_O0090_ALF_CHROMA_FILTER_ALTERNATIVES_CTB 1 // JVET-O0090 test 2: CTB selection of ALF alternative chroma filters
#define JVET_O0216_ALF_COEFF_EG3 1 // JVET-O0216/O0302/O0648: using EG3 for ALF coefficients coding
#define JVET_O0256_ADJUST_THD_DEPQUANT 1 // JVET-O0256: Fast encoder with adjusted threshold in dependent quantization
#define JVET_O0619_GTX_SINGLE_PASS_TS_RESIDUAL_CODING 1 // JVET-O0619/O0623 : Single pass coding of abs_level_gtx_flag[x] for TS residual coding
#define JVET_O0272_LMCS_SIMP_INVERSE_MAPPING 1 // JVET-O0272: LMCS simplified inverse mapping
#define JVET_O0247_ALF_CTB_CODING_REDUNDANCY_REMOVAL 1 // JVET-O0247: not signal APS index when number APS is 2
#define JVET_O0297_DMVR_PADDING 1 // JVET-O0297 DMVR Padding
#define JVET_O0637_CHROMA_GRADIENT_LINE_SELECTION 1 // Choose line0 and line3 for gradient computation when chroma is same size as luma
#define JVET_O0288_UNIFY_ALF_SLICE_TYPE_REMOVAL 1 // JVET-O0288: remove slice type dependency in ALF
#define JVET_O0064_SIMP_ALF_CLIP_CODING 1 // JVET-O0047/O0058/O0064/O0067/O0290/O0301/O0430: use FLC for alf clipping indices, always signal alf clipping indices
#define JVET_O0529_IMPLICIT_MTS_HARMONIZE 1 // JVET-O0529/O0540: Harmonization of LFNST, MIP and implicit MTS
#define JVET_O0669_REMOVE_ALF_COEFF_PRED 1 // JVET-O0425/O0427/O0669: remove prediction in ALF coefficients coding
#define JVET_O0541_IMPLICIT_MTS_CONDITION 1 // JVET_O0541: Decouple the intra implicit transform selection from an inter MTS related SPS flag
#define JVET_O0163_REMOVE_SWITCHING_TMV 1 // JVET-O0163/JVET-O0588: Remove switching between L0 and L1 for temporal MV
#define JVET_O0655_422_CHROMA_DM_MAPPING_FIX 1 // JVET-O0655: modify chroma DM derivation table for 4:2:2 chroma format
#define JVET_O1109_UNFIY_CRS 1 // JVET-O1109: Unified CRS derivation
#define JVET_O0590_REDUCE_DMVR_ORIG_MV_COST 1 // Reduce the DMVR cost of the original MV
#define JVET_O0432_LMCS_ENCODER 1 // JVET-O0432: LMCS encoder improvement
#define JVET_O0429_CRS_LAMBDA_FIX 1 // JVET-O0429: fix encoder lambda rounding used in CRS
#define JVET_O0428_LMCS_CLEANUP 1 // JVET-O0428: LMCS cleanups
#define JVET_O0164_REMOVE_AMVP_SPATIAL_SCALING 1 // JVET-O0164/JVET-O0587: remove spatial AMVP candidate scaling
#define JVET_O0162_IBC_MVP_FLAG 1 // JVET-O0162/O0331/O0480/O0574: IBC mvp flag conditioned on MaxNumMergeCand>1
#define JVET_O0055_INT_DMVR_DIS_BDOF 1 // integer-distance DMVR cost to disable BDOF and disable BDOF early termination
#define JVET_O0277_INTRA_SMALL_BLOCK_DCTIF 1 // JVET-O0277: DCT-IF interpolation filter is always used for 4x4, 4x8, and 8x4 luma CB
#define JVET_O0267_IBC_SCALING_LIST 1
#define JVET_O0280_SIMD_TRIANGLE_WEIGHTING 0 // JVET-O0280: SIMD implementation for weighted sample prediction process of triangle prediction mode
#define JVET_O0364_PDPC_DC 1 // JVET-O0364 Part 4: align PDPC process for DC with the one for Planar
#define JVET_O0364_PDPC_ANGULAR 1 // JVET-O0364 Part 5: simplify PDPC process for angular modes
#define JVET_O0094_LFNST_ZERO_PRIM_COEFFS 1 // JVET-O0049: CE6-2.1a, LFNST involves zeroing of primary only coefficient positions
#define JVET_O0294_TRANSFORM_CLEANUP 1 // JVET-O0294: Context modelling for MTS index
#define JVET_O1124_ALLOW_CCLM_COND 1 // JVET-O1124/JVET-O0196: CCLM restriction to reduce luma-chroma latency for chroma separate tree
#define JVET_O0078_SINGLE_HMVPLUT 1 // JVET-O0078Single HMVP table for all CUs inside the shared merge list region for IBC
#define JVET_O0126_BPWA_INDEX_CODING_FIX 1 // JVET-O0126 align BPWA index coding with specification
#define JVET_O0592_ENC_ME_IMP 1 // JVET-O0592 encoder ME improvement
#define JVET_O0108_DIS_DMVR_BDOF_CIIP 1 // JVET_O0108 CE9-2.2: disable DMVR and BDOF for CIIP
#define JVET_O1140_SLICE_DISABLE_BDOF_DMVR_FLAG 1 // JVET-O1140 slice level disable flag for BDOF and DMVR
#define JVET_O0567_MVDRange_Constraint 1 // JVET-O0567: constrain the signalled MVD value to the range of [-2^17, 2^17-1]
#define JVET_O0596_CBF_SIG_ALIGN_TO_SPEC 1 // JVET-O0596 align cbf signaling with specification
#define JVET_O0193_REMOVE_TR_DEPTH_IN_CBF_CTX 1 // JVET-O0193/JVET-O0375: remove transform depth in cbf context modeling
#define JVET_O0594_BDOF_REF_SAMPLE_PADDING 1 // JVET-O0594/O0252/O0506/O0615/O0624: BDOF reference sample padding using the nearest integer sample position
https://www.sendspace.com/file/6w2ryp

[Jamaika]

New VVC codec v5.2 08.08.2019
#define JVET_O0119_BASE_PALETTE_444 1 // JVET-O0119: Palette mode in HEVC and palette mode signaling in JVET-N0258. Only enabled for YUV444.
#define JVET_O0304_SIMPLIFIED_BDOF 1 // JVET-O0304: Reduction of number of multiplications in BDOF
#define JVET_O0455_IBC_MAX_MERGE_NUM 1 // JVET-O0455: Control the max number of IBC merge candidates independently from regular merge candidates
#define JVET_O0650_SIGNAL_CHROMAQP_MAPPING_TABLE 1 // JVET-O0650: Signal chroma QP mapping tables and move chroma PPS/slice offsets after mapping table
#define JVET_O0502_ISP_CLEANUP 1 // JVET-O0502: Enable PDPC and all 67 intra modes and apply the cubic filter always (also included in JVET-O0341) for ISP
#define JVET_O0640_PICTURE_SIZE_CONSTRAINT 1 // JVET-O0640: Picture width and height shall be a multiple of Max(8, minCU size)
#define JVET_O_MAX_NUM_ALF_APS_8 1 // JVET-O: number of ALF APSs is reduced to 8
#define JVET_O0925_MIP_SIMPLIFICATIONS 1 // JVET-O0925: Simplifications of MIP
#define JVET_O0070_PROF 1 // JVET-O0070 method 4-2.1a: Prediction refinement with optical flow for affine mode
#define JVET_O0570_GRAD_SIMP 1 // JVET-O0570/JVET-O0211, SMID friendly spatial gradient calculation
#define JVET_O1170_IBC_VIRTUAL_BUFFER 1 // JVET-O1170/O1171: IBC virtual buffer
#define JVET_O1170_CHECK_BV_AT_DECODER 1 // For decoder to check if a BV is valid or not
#define JVET_O0538_SPS_CONTROL_ISP_SBT 1 // JVET-O0538: SPS control for ISP and SBT transform
#define JVET_O0634_BDOF_SIZE_CONSTRAINT 1 // JVET-O0634: BDOF applied CU size align with DMVR
#define JVET_O0213_RESTRICT_LFNST_TO_MAX_TB_SIZE 1 // JVET-O0213: Block size restriction of LFNST to maximum transform size
#define JVET_O0617_SIG_FLAG_CONTEXT_REDUCTION 1 // JVET-O0617: Significant flag context reduction
#define JVET_O0244_DELTA_POC 1 // JVET-O0244: weighted prediction in SPS and delta POC
#define JVET_O1153_INTRA_CHROMAMODE_CODING 1 //JVET-O1153: simplified intra chromamode coding
#define JVET_O0159_10BITTCTABLE_DEBLOCKING 1 // tc table for 10-bit video
#define JVET_O0061_MV_THR_DEBLOCKING 1 // a deblocking mv threshold of half pel
#define JVET_O0220_METHOD1_SUBBLK_FLAG_PARSING 1 // JVET-O0220 method-1: Parse merge_subblock_flag conditioned on MaxNumSubblockMergeCand
#define JVET_O0263_O0220_SUBBLOCK_SYNTAX_CLEANUP 1 // JVET-O0263/ JVET-O0220: Syntax cleanup on subblock merge
#define JVET_O0060_4x4_deblocking 1 // deblock on 4x4 grid
#define JVET_O0046_DQ_SIGNALLING 1 // JVET-O0046: Move delta-QP earlier for 64x64 VPDU processing, applied to CUs >64x64 only
#define JVET_O0616_400_CHROMA_SUPPORT 1 // JVET-O0616: Various chroma format support in VVC
#define JVET_O0265_TPM_SIMPLIFICATION 1 // JVET-O0265/JVET-O0629/JVET-O0418/JVET-O0329/JVET-O0378/JVET-O0411/JVET-O0279:Simplified motion field storage for TPM
#define JVET_O0409_EXCLUDE_CODED_SUB_BLK_FLAG_FROM_COUNT 1 // JVET-O0409: exclude coded_subblock_flag from counting context-coded bins in transform skip
#define JVET_O0057_ALTHPELIF 1 //AMVR_HPEL
#define JVET_O1136_TS_BDPCM_SIGNALLING 1 // JVET-O1136: Unified syntax for JVET-O0165/O0200/O0783 on TS and BDPCM signalling
#define JVET_O0219_LFNST_TRANSFORM_SET_FOR_LMCMODE 1
#define JVET_O0426_MRL_REF_SAMPLES_DC_MODE 1 // JVET-O0426: align MRL reference samples used for DC intra mode prediction
#define JVET_O0366_AFFINE_BCW 1 // JVET-O0366: Simplifications on BCW index derivation process
#define JVET_O0919_TS_MIN_QP 1 // JVET-O0919: Minimum QP for Transform Skip Mode
#define JVET_O1168_CU_CHROMA_QP_OFFSET 1 // JVET-O1168: cu chroma QP offset
#define JVET_O0368_LFNST_WITH_DCT2_ONLY 1 // JVET-O0368/O0292/O0521/O0466: disable LFNST for non-DCT2 MTS candidates normatively
#define JVET_O0106_ISP_4xN_PREDREG_FOR_1xN_2xN 1 // JVET-O0106: use 4xN prediction regions for 1xN and 2xN subblocks
#define JVET_O0500_SEP_CTX_AFFINE_SUBBLOCK_MRG 1 // JVET-O0500: Different ctx models for inter affine flag and subblock merge flag
#define JVET_O0414_SMVD_LTRP 1 // JVET-O0414: long-term reference picture restriction for SMVD
#define JVET_O0258_REMOVE_CHROMA_IBC_FOR_DUALTREE 1 // JVET-O0258 Remove chroma IBC when dualtree is used
#define JVET_O1161_IBC_MAX_SIZE 1 // Limit largest IBC luma CU size to 64x64 per discussion of JVET-O1161
#define JVET_O0315_RDPCM_INTRAMODE_ALIGN 1 // JVET-O0200/O0205/O0296/O0342/O0463/O0542: Intra prediction mode alignment for BDPCM
#define JVET_O0284_CONDITION_SMVD_MVDL1ZEROFLAG 1 // JVET-O0284: condition sym_mvd_flag on mvd_l1_zero_flag
#define JVET_O0122_TS_SIGN_LEVEL 1 // JVET-O0122: Sign context and level mapping of TS residual coding.
#define JVET_O0438_SPS_AFFINE_AMVR_FLAG 1 // JVET-O0438: affine AMVR control flag conditioned on affine control flag in SPS
#define JVET_O0065_CABAC_INIT 0 // JVET-O0065: CABAC initialization
#define JVET_O0052_TU_LEVEL_CTX_CODED_BIN_CONSTRAINT 1 // JVET-O0052 Method-1: TU-level context coded bin constraint
#define JVET_O0105_ICT 1 // JVET-O0105: inter-chroma transform (ICT) as extension of joint chroma coding (JCC)
#define JVET_O0543_ICT_ICU_ONLY 1 // JVET-O0543: ICT only in Intra CUs (was Intra slices, modified during adoption)
#define JVET_N0288_PROPOSAL1 1 // JVET-N0288 Proposal 1
#define JVET_O0090_ALF_CHROMA_FILTER_ALTERNATIVES_CTB 1 // JVET-O0090 test 2: CTB selection of ALF alternative chroma filters
#define JVET_O0050_LOCAL_DUAL_TREE 1 // JVET-O0050: avoid small intra chroma block by a "local dual-tree" technique
#define JVET_O0216_ALF_COEFF_EG3 1 // JVET-O0216/O0302/O0648: using EG3 for ALF coefficients coding
#define JVET_O0256_ADJUST_THD_DEPQUANT 1 // JVET-O0256: Fast encoder with adjusted threshold in dependent quantization
#define JVET_O0619_GTX_SINGLE_PASS_TS_RESIDUAL_CODING 1 // JVET-O0619/O0623 : Single pass coding of abs_level_gtx_flag[x] for TS residual coding
#define JVET_O0272_LMCS_SIMP_INVERSE_MAPPING 1 // JVET-O0272: LMCS simplified inverse mapping
#define JVET_O0247_ALF_CTB_CODING_REDUNDANCY_REMOVAL 1 // JVET-O0247: not signal APS index when number APS is 2
#define JVET_O0297_DMVR_PADDING 1 // JVET-O0297 DMVR Padding
#define JVET_O0637_CHROMA_GRADIENT_LINE_SELECTION 1 // Choose line0 and line3 for gradient computation when chroma is same size as luma
#define JVET_O0288_UNIFY_ALF_SLICE_TYPE_REMOVAL 1 // JVET-O0288: remove slice type dependency in ALF
#define JVET_O0064_SIMP_ALF_CLIP_CODING 1 // JVET-O0047/O0058/O0064/O0067/O0290/O0301/O0430: use FLC for alf clipping indices, always signal alf clipping indices
#define JVET_O0529_IMPLICIT_MTS_HARMONIZE 1 // JVET-O0529/O0540: Harmonization of LFNST, MIP and implicit MTS
#define JVET_O0669_REMOVE_ALF_COEFF_PRED 1 // JVET-O0425/O0427/O0669: remove prediction in ALF coefficients coding
#define JVET_O0526_MIN_CTU_SIZE 1 // JVET-O0526: Minimum CTU size 32x32
#define JVET_O0545_MAX_TB_SIGNALLING 1 // JVET-O0545: Configurable maximum transform size
#define JVET_O0541_IMPLICIT_MTS_CONDITION 1 // JVET_O0541: Decouple the intra implicit transform selection from an inter MTS related SPS flag
#define JVET_O0163_REMOVE_SWITCHING_TMV 1 // JVET-O0163/JVET-O0588: Remove switching between L0 and L1 for temporal MV
#define JVET_O0655_422_CHROMA_DM_MAPPING_FIX 1 // JVET-O0655: modify chroma DM derivation table for 4:2:2 chroma format
#define JVET_O1109_UNFIY_CRS 1 // JVET-O1109: Unified CRS derivation
#define JVET_O0590_REDUCE_DMVR_ORIG_MV_COST 1 // Reduce the DMVR cost of the original MV
#define JVET_O0432_LMCS_ENCODER 1 // JVET-O0432: LMCS encoder improvement
#define JVET_O0429_CRS_LAMBDA_FIX 1 // JVET-O0429: fix encoder lambda rounding used in CRS
#define JVET_O0428_LMCS_CLEANUP 1 // JVET-O0428: LMCS cleanups
#define JVET_O0164_REMOVE_AMVP_SPATIAL_SCALING 1 // JVET-O0164/JVET-O0587: remove spatial AMVP candidate scaling
#define JVET_O0162_IBC_MVP_FLAG 1 // JVET-O0162/O0331/O0480/O0574: IBC mvp flag conditioned on MaxNumMergeCand>1
#define JVET_O0055_INT_DMVR_DIS_BDOF 1 // integer-distance DMVR cost to disable BDOF and disable BDOF early termination
#define JVET_O0277_INTRA_SMALL_BLOCK_DCTIF 1 // JVET-O0277: DCT-IF interpolation filter is always used for 4x4, 4x8, and 8x4 luma CB
#define JVET_O0267_IBC_SCALING_LIST 1
#define JVET_O0280_SIMD_TRIANGLE_WEIGHTING 0 // JVET-O0280: SIMD implementation for weighted sample prediction process of triangle prediction mode
#define JVET_O0379_SPEEDUP_TPM_ENCODER 1 // JVET_O0379: Speedup mode decision process for triangle prediction mode
#define JVET_O0364_PADDING 1 // JVET-O0364 Part 2: clean up padding process in intra prediction
#define JVET_O0364_PDPC_DC 1 // JVET-O0364 Part 4: align PDPC process for DC with the one for Planar
#define JVET_O0364_PDPC_ANGULAR 1 // JVET-O0364 Part 5: simplify PDPC process for angular modes
#define JVET_O0094_LFNST_ZERO_PRIM_COEFFS 1 // JVET-O0049: CE6-2.1a, LFNST involves zeroing of primary only coefficient positions
#define JVET_O0294_TRANSFORM_CLEANUP 1 // JVET-O0294: Context modelling for MTS index
#define JVET_O1124_ALLOW_CCLM_COND 1 // JVET-O1124/JVET-O0196: CCLM restriction to reduce luma-chroma latency for chroma separate tree
#define JVET_O0078_SINGLE_HMVPLUT 1 // JVET-O0078Single HMVP table for all CUs inside the shared merge list region for IBC
#define JVET_O0126_BPWA_INDEX_CODING_FIX 1 // JVET-O0126 align BPWA index coding with specification
#define JVET_O0592_ENC_ME_IMP 1 // JVET-O0592 encoder ME improvement
#define JVET_O0108_DIS_DMVR_BDOF_CIIP 1 // JVET_O0108 CE9-2.2: disable DMVR and BDOF for CIIP
#define JVET_O1140_SLICE_DISABLE_BDOF_DMVR_FLAG 1 // JVET-O1140 slice level disable flag for BDOF and DMVR
#define JVET_O0567_MVDRange_Constraint 1 // JVET-O0567: constrain the signalled MVD value to the range of [-2^17, 2^17-1]
#define JVET_O0596_CBF_SIG_ALIGN_TO_SPEC 1 // JVET-O0596 align cbf signaling with specification
#define JVET_O0193_REMOVE_TR_DEPTH_IN_CBF_CTX 1 // JVET-O0193/JVET-O0375: remove transform depth in cbf context modeling
#define JVET_O0681_DIS_BPWA_CIIP 1 // JVET-O0681 disable BCW for CIIP, method 2 inherit BCW index
#define JVET_O0249_MERGE_SYNTAX 1 // JVET-O0249: merge syntax change
#define JVET_O0594_BDOF_REF_SAMPLE_PADDING 1 // JVET-O0594/O0252/O0506/O0615/O0624: BDOF reference sample padding using the nearest integer sample position
#define JVET_O0376_SPS_JOINTCBCR_FLAG 1 // JVET-O0376: add the JointCbCr control flag in SPS
#define JVET_O0472_LFNST_SIGNALLING_LAST_SCAN_POS 1 // JVET-O0472: LFNST index signalling depends on the position of last significant coefficient
https://www.sendspace.com/file/2hd62d

https://jvet.hhi.fraunhofer.de/trac/vvc/ticket/428
WPP & SPLIT PARALLELISM options are not really maintained. Patches are still appreciated, but may be worked on only with very low priority.
Some comments:
JVET_O macros are normative changes. These can't just be turned off.

55:#include "mingw.mutex.h"

seems very platform specific.

[jonatans]

So nothing new came out of the MC-IF meeting?

https://www.mc-if.org/mc-if-meeting-and-outreach

Sorry for the late response. There was a press release after the Yokohama meeting: https://www.businesswire.com/news/home/20190619005114/en/Media-Coding-Industry-Forum-Establishes-Work-Groups although it is only a very high level overview of the event - most of the actual work happens in the work groups.

Next MC-IF event will be held in Amsterdam during IBC: https://www.mc-if.org/ (https://www.mc-if.org/), direct link to: invitation letter (https://docs.wixstatic.com/ugd/0c1418_2354c6bb29024a5984357f83988eb899.pdf)

[Adonisds]

When do you think VVC will reach the market? When it does, will it be possible to use a PC with an old CPU to play AV1 and VVC videos if you buy a new video card?

[hajj_3]

When do you think VVC will reach the market? When it does, will it be possible to use a PC with an old CPU to play AV1 and VVC videos if you buy a new video card?

It will be ratified by the end of 2020. Yes a new gpu that has a VVC hardware decoder would let you decode it smoothly.

[Jamaika]

New VVC codec v6.0 18.08.2019 with application HDRTools and WPP & SPLIT PARALLELISM
https://gitlab.com/standards/HDRTools/tree/0.19-dev

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

[iwod]

When do you think VVC will reach the market? When it does, will it be possible to use a PC with an old CPU to play AV1 and VVC videos if you buy a new video card?

It depends, AV1's software decoding is still progressing, but judging from the presentation, I still think VVC will be easier to decode than AV1, both in Hardware and Software.

Of course companies are waiting for licensing, which is what MC-IF was suppose to solve / improve. While there were no official announcement, I believe Velos Media wasn't listed in 2018, and it is now included in members page means All major player in the HEVC licensing are under MC-IF. Even those who refuse to participate with MPEG-LA or other patents pool are there as well like Technicolor.

This is a very encouraging sign. Hopefully the licensing terms will be out as soon as the codec get finalised.

[benwaggoner]

It depends, AV1 is software decoding is still progressing, but judging from the presentation, I still think VVC will be easier to decode than AV1, but in Hardware and Software.

Of course companies are waiting for listening, which is what MC-IF was suppose to solve / improve. While there were no official announcement, I believe Velos Media wasn't listed in 2018, and now it has included in its members page means All major player in the HEVC licensing are under MC-IF. Even those who refuse to participate with MPEG-LA or other patents pool are here like Technicolor.

This is a very encouraging sign. Hopefully the listening terms will be out as soon as the codec is finalise.
Yeah, so much about AV1's future is dependent on codec licensing and businesss issues that AOM has no control over.

VVC will definitely offer better compression efficiency than AV1, and it seems increasingly probably it can do so with fewer MIPS/watts/mm^2 of silicon.

Of course, the more viable AV1 is, the more pressure there would be on VVC patent holders to come up with a clearer licensing story than HEVC has been dealing with.

[iwod]

Yeah, so much about AV1's future is dependent on codec licensing and businesss issues that AOM has no control over.

VVC will definitely offer better compression efficiency than AV1, and it seems increasingly probably it can do so with fewer MIPS/watts/mm^2 of silicon.

Of course, the more viable AV1 is, the more pressure there would be on VVC patent holders to come up with a clearer licensing story than HEVC has been dealing with.

LOL, my original post was so full of spelling mistakes I couldn't even comprehend what I was trying to say.

Competition is great.

But I do see the need of Free to use Codec, I just wish they could allow VVC to be royalty free for software uses, and only collect royalty on dedicated hardware.

[Jamaika]

VVC codecs after the holidays
Unfortunately, the VVC codec is working more slowly. They are currently underdeveloped. Will there be any improvements to coding speed? Is unknown. HDR HLG functions are currently being finalized.

Opensource HLG https://www.isovideo.com/SDR_to_HLG10_Up_Conversion_Examples.php
Adds VVC 6.1 codecs NONE/SSE41/SSE42/AVX/AVX2 (Codec AVX512 doesn't create in Windows with function -mavx512)
https://www.sendspace.com/file/0qb856

[benwaggoner]

LOL, my original post was so full of spelling mistakes I couldn't even comprehend what I was trying to say.

Competition is great.

But I do see the need of Free to use Codec, I just wish they could allow VVC to be royalty free for software uses, and only collect royalty on dedicated hardware.
I'm also very interested to see where EVC/MPEG-5 fits into the decision matrix. That spec is supposed to be done around end of the year.

[benwaggoner]

VVC codecs after the holidays
Unfortunately, the VVC codec is working more slowly. They are currently underdeveloped. Will there be any improvements to coding speed? Is unknown. HDR HLG functions are currently being finalized.

Opensource HLG https://www.isovideo.com/SDR_to_HLG10_Up_Conversion_Examples.php
Adds VVC 6.1 codecs NONE/SSE41/SSE42/AVX/AVX2 (Codec AVX512 doesn't create in Windows with function -mavx512)
https://www.sendspace.com/file/0qb856
Performance optimization of MPEG reference encoders isn't a huge priority. Generally they make it fast enough to make experimentation possible, but assume actual commercial encoders are where practical speed/quality improvements go.

VPx and AV1 have been kind of unique in having a reference encoder that is also the primary production encoder. Although that is more due to the relative lack of a market for commercial VPx encoders historically.

[Jamaika]

Performance optimization of MPEG reference encoders isn't a huge priority. Generally they make it fast enough to make experimentation possible, but assume actual commercial encoders are where practical speed/quality improvements go.
What surprises me when encoding VVC?
When I convert material already processed by HEVC, the VVC codec encodes much faster than source. However, do I see these differences in quality video for QP32? No
Thread support is troublesome. There is a combination of POSIX <thread>, <mutex> and linux <pthread> functions which is incorrect. You can't add thread larger than one.
VPx and AV1 have been kind of unique in having a reference encoder that is also the primary production encoder. Although that is more due to the relative lack of a market for commercial VPx encoders historically.
For me the big surprise is the AV1 MPEG-4.

[Jamaika]

Tutorial: Generate Microsoft Visual Studio Solution for VTM+360Lib— 360-Degree Video Using VVC Codec (Video Coding) (https://medium.com/@sh.tsang/tutorial-generate-microsoft-visual-studio-solution-for-vtm-360lib-360-degree-video-using-vvc-7ee40aa957f4)

Compared to HEVC/H.265, VVC/H.266 should allow data rate savings of up to 50%, according to the German research institute. Thus, a more efficient data transmission is possible in the fixed and especially in the mobile network, where data capacity is limited. For example, a 90-minute Ultra HD video encoded with HEVC/H.265 currently requires around 10GB of data, while with VVC/H.266 it will only take up around 5GB.

[iwod]

Tutorial: Generate Microsoft Visual Studio Solution for VTM+360Lib— 360-Degree Video Using VVC Codec (Video Coding) (https://medium.com/@sh.tsang/tutorial-generate-microsoft-visual-studio-solution-for-vtm-360lib-360-degree-video-using-vvc-7ee40aa957f4)

Compared to HEVC/H.265, VVC/H.266 should allow data rate savings of up to 50%, according to the German research institute. Thus, a more efficient data transmission is possible in the fixed and especially in the mobile network, where data capacity is limited. For example, a 90-minute Ultra HD video encoded with HEVC/H.265 currently requires around 10GB of data, while with VVC/H.266 it will only take up around 5GB.

That is 15Mbps for HEVC, who the hell do that on a mobile network?

All these figures are always giving best case scenario, i want a 50% saving in low end, 2-4Mbps range.

Last time I read, VVC communities would actually like to push for more than 50% savings. I wonder if that is still the case.

[benwaggoner]

That is 15Mbps for HEVC, who the hell do that on a mobile network?
That is possible on some LTE networks already. It is pretty trivial for WiFi.

All these figures are always giving best case scenario, i want a 50% saving in low end, 2-4Mbps range.

Last time I read, VVC communities would actually like to push for more than 50% savings. I wonder if that is still the case.
It's hard to predict the savings of a new codec without production-ready encoder implementations, but everything I hear suggests that VVC is quite plausibly capable of delivering the same perceptual quality as HEVC at half the bitrate, with encoders with similar degrees of development. It'll take a while before a generalized 50% would become available, though, as HEVC encoders are way more mature. There's more scope in adapting a VVC encoder from an HEVC one than, say, a AV1 encoder from a HEVC, since the foundation is a lot similar. One could take an existing HEVC encoder and start adding features from the VVC reference encoder and get to a compliant bitstream pretty quickly, and then start iterating on newer tools and quality tuning.

[benwaggoner]

What surprises me when encoding VVC?
When I convert material already processed by HEVC, the VVC codec encodes much faster than source. However, do I see these differences in quality video for QP32? No
Do you mean you aren't seeing a subjective difference in quality at QP32 between HEVC and VVC?

For me the big surprise is the AV1 MPEG-4.
What about it? There was a mapping for VP9 to MPEG-4 IIRC.

The MPEG-4 file format and systems layer are very mature with a huge ecosystem around it, and without codec-specific patent issues. The QuickTime file format that it was based on was extremely flexible. It's hard to imagine what value there would be in a whole new file format or systems layer that couldn't be better within or as extensions to MPEG-4.

For professional content, it's really all MPEG-4. MKV is the other format I see used some, but mainly for personal use, and I don't think there is anything MKV can do that MPEG-4 can't; it's more about the installed base of authoring tools and players for MKV. A generic MPEG-4 player wouldn't have the UI to use all the tracks and other info that could be in a MKV-parity MPEG-4 file, so having a different extension is helpful.

[Jamaika]

Do you mean you aren't seeing a subjective difference in quality at QP32 between HEVC and VVC?
I'm not seeing a subjective difference. I did the test for HD. Maybe we are talking about large 8K sizes.
One could take an existing HEVC encoder and start adding features from the VVC reference encoder and get to a compliant bitstream pretty quickly, and then start iterating on newer tools and quality tuning.
From what I see, there is no desire for HEVC to follow this direction. The introduction of VVC also means the replacement of TV sets.

[Jamaika]

Adds VVC 6.1 codecs NONE{HDRTools}/NONE{360°}/SSE41/SSE42/AVX/AVX2 (library 360° & AVX512 doesn't create video in Windows with function -mavx512)

https://www.sendspace.com/file/5rgdpv

[FranceBB]

Adds VVC 6.1 codecs NONE{HDRTools}/NONE{360°}/SSE41/SSE42/AVX/AVX2 (library 360° & AVX512 doesn't create video in Windows with function -mavx512)

https://www.sendspace.com/file/5rgdpv

Thank you for the updated binary. :)

I wanted to test it again, so I decided to use a few files from a lazy day at work when we went outside and we shot a few samples in 4K Log-C XAVC Intra Class 300 500 Mbit/s. They're gonna be with my ugly face on them, sorry about that. Anyway, I'm trying to encode them in H.266 but it's not only taking an eternity, it's also not very well parallelized as it's using 1 core at a time at 100% on my Dual Xeon setup.
This wouldn't be a big deal, except for the fact that there's no percentage and no estimation, I have to check myself for which frame it has encoded and make a guess.
Can I ask you a progress/percentage/number of frames encoded output in cmd like the one we have in x264/x265 or even like the one in ffmpeg/ffmbc?
I mean, at the current stage of things there's just the terminal showing how each and every frame is encoded and it's taking minutes, literally minutes to encode a single frame and I have two Intel Xeon E5-2630 v3 overclocked at 3.00GHz (from the stock 2.40 GHz), for a total of 16 core, 32 threads and 40 MB of cache L3 and support to instructions up to AVX2 and 32GB of RAM, not exactly a crappy hardware.

Img1: Link (https://i.imgur.com/LYxnCQA.png)
Img2: Link (https://i.imgur.com/QHbYBin.png)
Img3: Link (https://i.imgur.com/zVLKDMC.png)


This is what I mean:

https://i.imgur.com/hqlqPhY.png

https://i.imgur.com/nA2W3CY.png

The AVS Script is just a simple append:


FFVideoSource("Y:\France\FILE format\File_Test_France\Canon EOS R (Clog)\KU6A0648.MP4")
video1=last
FFVideoSource("Y:\France\FILE format\File_Test_France\Canon EOS R (Clog)\KU6A0649.MP4")
video2=last
FFVideoSource("Y:\France\FILE format\File_Test_France\Canon EOS R (Clog)\KU6A0650.MP4")
video3=last
FFVideoSource("Y:\France\FILE format\File_Test_France\Canon EOS R (Clog)\KU6A0652.MP4")
video4=last
FFVideoSource("Y:\France\FILE format\File_Test_France\Canon EOS R (Clog)\KU6A0653.MP4")
video5=last
FFVideoSource("Y:\France\FILE format\File_Test_France\Canon EOS R (Clog)\KU6A0655.MP4")
video6=last

video1++video2++video3++video4++video5++video6


And the BAT is the following one:


@echo off

C:\encoder\encoder\Processors\ffmpeg\x86\ffmpeg.exe -y -loglevel error -i "C:\Encoding\file1.avs" -an -f rawvideo -strict -1 lossless.yuv

pause

EncoderApp_avx.exe --SummaryVerboseness -c "encoder_randomaccess_vtm.cfg" --InputFile=lossless.yuv --BitstreamFile=logc4ktest.vvc --SourceWidth=3840 --SourceHeight=2160 --FrameRate=25 --InputColorPrimaries=1 --InputSampleRange=1 --InputBitDepth=8 --InternalBitDepth=10 --OutputBitDepth=10 --MSBExtendedBitDepth=10 --InputChromaFormat=420 --ChromaFormatIDC=420 --MatrixCoefficients=9 --ConformanceWindowMode=1 --FramesToBeEncoded=1334 --AspectRatioInfoPresent=1 --VideoSignalTypePresent=1 --ChromaLocInfoPresent=1 --VideoFullRange=1

pause


With 16 GB worth of lossless uncompressed video I had to encode out of 1334 frames in XAVC Intra Class 300 4K 25fps.


Source (XAVC Intra Class 300):
Part 1: https://we.tl/t-xvfMxO4dag
Part 2: https://we.tl/t-D4jY7OtqM4


Encoded (H.266 VVC - Incomplete -):
Link: https://we.tl/t-zWSxzCSeF8

(I'm gonna upload the encoded file as soon as it finishes to encode). :)


EDIT: Alright folks, I fired up the encode at 09 AM. It's 5PM over here and it's still far from the end, but I gotta go and I can't keep my computer busy. I stopped the encode and I uploaded what my Xeon managed to encode so far after 8 hours of encoding. If someone else wants to try to encode it, feel free to do it.
I gotta say that I do wanna help with VVC testing, however if it takes so much time to encode on such a powerful machine it becomes hard for me to help...

[Jamaika]

I'm trying to encode them in H.266 but it's not only taking an eternity, it's also not very well parallelized as it's using 1 core at a time at 100% on my Dual Xeon setup.
There should be two by four cores when adding libgomp, but for gcc it's not. I suppose there is a bug in the VVC software.
In X265 with threads four, Number Wpp Threads is equal to two.
Is this an OpenMP software problem? I don't know. I know that VS2019 is the latest version 5.0, not 3.0 for libgomp.
This wouldn't be a big deal, except for the fact that there's no percentage and no estimation, I have to check myself for which frame it has encoded and make a guess.
Can I ask you a progress/percentage/number of frames encoded output in cmd like the one we have in x264/x265 or even like the one in ffmpeg/ffmbc?
For config "encoder_randomaccess_vtm.cfg" isn't P-frames.
Number of frames encoded output is function "FramesToBeEncoded". There is actually no percentage of processed film.
(I'm gonna upload the encoded file as soon as it finishes to encode).
It is a pity to damage the equipment.

I will only add that they are thinking about AVX2 & 360 suport. The codec doesn't currently work
https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/merge_requests/920

PS It is interesting for me why VVC codec is developed on HM-HEVC and not on Mainconcept, Leadtools, other HEVC.
There are currently a waste of time for novelties that are unlikely to come soon. Fast entry means throwing away all receivers HEVC.

https://www.ibc.org/create-and-produce/generation-hevc/4252.article
Except that the implementation is not as easy as it may seem. All MPEG-based codecs (including AVC/H.264, HEVC/H.265 and VVC) make use of similarities between consecutive pictures. This means each encoding block needs to know about subsequent or previous images, as well as neighboring blocks. Any shortcut taken here will invariably lead to image quality degradation, and any over-engineering in the control mechanism will sacrifice the benefit of parallel processing. We aren't interested in this

Is Hybrid GPU Encoding the ultimate answer? As every use case is different, there is no single best answer. However, Hybrid GPU accelerated encoding delivers faster processing, allowing for more live channels per server, with less demand for CPU power when encoding. But, the performance of the encoder depends on a variety of factors such as the desired encoding profile, resolution, server system, GPU model, etc. In today’s world of ever-increasing quality and performance requirements, especially for live video, GPU Hybrid offers flexibility to get the most out of your investment.

[FranceBB]

Except that the implementation is not as easy as it may seem. All MPEG-based codecs (including AVC/H.264, HEVC/H.265 and VVC) make use of similarities between consecutive pictures. This means each encoding block needs to know about subsequent or previous images, as well as neighboring blocks. Any shortcut taken here will invariably lead to image quality degradation, and any over-engineering in the control mechanism will sacrifice the benefit of parallel processing. We aren't interested in this

Well of course parallelization means a reduction of quality and ideally we should stick with single thread, however the increasing computational power required to encode led us to where we are now: a very parallelized world.
I gotta say, though, that H.264 and H.265 are very well parallelized and that although a very little reduction of quality can be proven via objective metrics like SSIM/PSNR in extreme parallelization, such a thing is so small that it's almost unnoticeable and H.265 in particular developed many internal tools in a way that they're meant to be used by multi-core/threads CPUs in a very efficient way.

Is Hybrid GPU Encoding the ultimate answer? As every use case is different, there is no single best answer. However, Hybrid GPU accelerated encoding delivers faster processing, allowing for more live channels per server, with less demand for CPU power when encoding. But, the performance of the encoder depends on a variety of factors such as the desired encoding profile, resolution, server system, GPU model, etc. In today’s world of ever-increasing quality and performance requirements, especially for live video, GPU Hybrid offers flexibility to get the most out of your investment.

Sure, GPU encoding is a thing, but GPU encoders have been proven to achieve less quality compared to CPU encoders in both x264 and x265 tests over the years.
Of course, things have improved ever since, but they still lack behind.
Anyway, the same parallelization concept applies: in the world we're living in, there's so much need to parallelize workflows that hybrid CPU/GPU encoding is almost always preferred, despite the loss of quality, which is not as negligible as it was for single-thread multi-thread CPU tests (heck, you can see with your eyes the difference between CPU encoders and GPU encoders).


On a totally unrelated thing...


Linear Algebra consideration:

I was taking a look at the official document about H.266 VVC.
I've stumbled across different transforms in my life, namely the DCT (Discrete Cosine Transform), DFT (Discrete Fourier Transform), WHT (Walsh-Hadamard Transform), DWT (Discrete Wavelet Transform) and of course the KLT (Karhunen-Loeve Transform).
The Discrete Cosine transform is widely used in many codecs and indeed it's my favorite transform 'cause it works with real numbers and it's continuous in 2 phi.
On the contrary, the Fourier Transform works with the imaginary numbers and it's continuous in phi, so not only it has more discontinuity points, but it also requires more computational power since it's using complex numbers.
As a matter of fact, in codecs like H.264 the DCT is used along with the Hadamard Transform which is very light and although it doesn't compress much, it's used in addition to the DCT in order to take care of what the DCT didn't properly take care of.
As to the Wavelet transform, it kinda became popular years ago when they were trying to take care of the blocking issues that were caused by quantizing 4x4 and 8x8 blocks with the Discrete Cosine Transform that was causing blocking artifacts that were not pleasant at not so high bitrates, therefore it was used in implementations like the JPEG2000 or AppleProres 'cause they were processing the whole image at the full resolution all at once, but I've never been a fan of this transform and as a matter of fact, although it has its own advantages and peculiarities, it's not as widespread as the DCT.
As to the Karhunen-Loeve transform, it became popular back in 2013 when we were all looking for alternatives when H.265 was still a work in progress and was on design-stage.
The Karnhunen-Loeve transform is probably the heaviest transform that I'm aware of and it requires a lot of computational power, however, during the tests, it was shown that although it was better than the Discrete Cosine Transform itself, it didn't actually achieve such a significant advantage over the Discrete Cosine Transform on a significant amount of contents, but it required way more computational power than the DCT and therefore the proposal at the time was rejected and the Discrete Cosine Tranform and the Discrete Sine Transform were used in H.265 instead.

Linear Algebra question:

If I got it right, H.266 VVC inherited the Discrete Cosine Transform and Discrete Sine Transform approach from H.265 HEVC which is fine, but it's also using an adaptive multiple transform (AMT) scheme for residual coding for both inter-coded and intra-coded blocks. This approach basically consists of a set of five DCT and DST based transform, namely DCT-II, DCT-V, DCT-VIII, DST-I, and DST-VII.
Fair enough, but how? I mean, I can't find an extensive documentation that fully explains how those are used.
Are they used subsequently? One after the other and in case in which order? Are they used with a sort of pre-filter which analyses the type of frame, divides it in blocks and macroblocks and decide which one it's gonna use or which set it's gonna use?

[Jamaika]

https://www.researchgate.net/publication/332073033_Analysis_of_Emerging_Video_Codecs_Coding_Tools_Compression_Efficiency_and_Complexity 10.2018
HEVC transform is based on a Discrete Cosine Transform (DCT-II), apart for Intra-coded 4x4 TUs for which a
Discrete Sine Transform (DST-VII) is used. In comparison, JEM relies on a variety of selectable core transforms from
the DCT and DST families (DCT-II, DCT-V, DCT-VII, DST-I and DST-VII). An Adaptive Multiple Transform (AMT)
method has been designed such that depending on the selected mode (intra or inter), or further on the intra prediction
direction, a sub-set of the core transforms is built and one transform from this sub-set is chosen based on RDO. In
the JEM, large block-size transforms, up to 128×128 in size, are enabled. High frequency transform coefficients are
zeroed out for the transform blocks with size larger than or equal to 64, so that only the lower-frequency coefficients
are maintained. In addition to AMT, a Mode-Dependent Non-Separable Secondary Transform (MDNSST) is applied
between the core transform and the quantization, with the motivation to reduce remaining dependencies after the
separable core transforms which only address horizontal and vertical signal dependencies. Finally a Signal
Dependent Transform (SDT) is competed to the AMT output. The SDT approximates the optimal Karhunen-Loéve
transform (KLT), which is a signal dependent transform, by estimating current signal to code (transform block) with
similar signals (i.e. reference patch) available at the decoder (already coded).
AV1 also supports multiple transforms: DCT, Asymmetric DST (ADST), flipped ADST, and Identity (IDTX). The
identity transform is equivalent to the transform skip mode of HEVC and JEM. The vertical and the horizontal
transforms can be selected independently from the set of four transforms, resulting in 16 transform combinations.

As to transform, the square transforms in HEVC are extended to non-square transforms for rectangular blocks resulted from binary and ternary tree splits. Besides, [VVC] supports multiple transform sets (MTS), including DCT-2, DST-7, and DCT-8 as well as the non-separable secondary transform. The transforms used in [VVC] can have different sizes with support for larger transform sizes. For DCT-2, the transform sizes range from 2x2 to 64x64, and for DST-7 and DCT-8, the transform sizes range from 4x4 to 32x32. In addition, [VVC] also support sub-block transform for both intra and inter coded blocks. For intra coded blocks, intra sub-partitioning (ISP) may be used to allow sub-block based intra prediction and transform. For inter blocks, sub-block transform may be used assuming that only a part of an inter-block has non-zero transform coefficients.

Increase max QP from 51 to 63. An enhanced rate distortion optimized quantization scheme called Dependent Scalar Quantization. CABAC coder from AVC, it has been enhanced and is now even faster.

[FranceBB]

An Adaptive Multiple Transform (AMT)
method has been designed such that depending on the selected mode (intra or inter)

Got it.


In addition to AMT, a Mode-Dependent Non-Separable Secondary Transform (MDNSST) is applied
between the core transform and the quantization, with the motivation to reduce remaining dependencies after the
separable core transforms which only address horizontal and vertical signal dependencies.


Ok, it makes sense.


Finally a Signal
Dependent Transform (SDT) is competed to the AMT output. The SDT approximates the optimal Karhunen-Loéve
transform (KLT), which is a signal dependent transform, by estimating current signal to code (transform block) with
similar signals (i.e. reference patch) available at the decoder (already coded).


Very interesting 'cause this way a lot of computational power is actually saved by not using the KLT directly which is far too demanding in terms of computational cost, but if this approximation gets similar results, I totally understand why they went for this path.


AV1 also supports multiple transforms: DCT, Asymmetric DST (ADST), flipped ADST, and Identity (IDTX).


Oh, I see... I gotta say that I'm not very familiar with AV1 'cause it's not very widespread in broadcast and nobody ever sent us a master file in AV1, but it's good to know.


The
identity transform is equivalent to the transform skip mode of HEVC and JEM.


Yeah, of course, it's just like when you multiply a matrix of linear transformation by the identity matrix (the matrix with all one on the main diagonal and zero everywhere else): you get back the matrix you started from. After all the identity it's there (in a space) for a reason: to get back the input as output :)


The vertical and the horizontal
transforms can be selected independently from the set of four transforms, resulting in 16 transform combinations.


I see, that's good.


the square transforms in HEVC are extended to non-square transforms for rectangular blocks resulted from binary and ternary tree splits.


I see! That's gonna increase the computational cost, but it's actually very good that they have been modified, so if they did it, it means that the result it's worth the cost.


CABAC coder from AVC, it has been enhanced and is now even faster.


Oh, that's great.


Alright, thank you for clarifying my doubts. I'm an young engineer and I have always been interested in applied mathematic. VVC has a lot of potential indeed and some of those things are really reassuring me about VVC and the role that it's gonna play in the future.
Speaking of future, Tokyo 2020 Olympics are gonna be in 8K and we're talking about summer 2020. Do you think that the encoder will be at a much more developed state at that point and it's actually gonna be used to encode and distribute live feeds or do you think that it's still way too early and everything it's gonna be done in HEVC as rumours suggest?

[benwaggoner]

Speaking of future, Tokyo 2020 Olympics are gonna be in 8K and we're talking about summer 2020. Do you think that the encoder will be at a much more developed state at that point and it's actually gonna be used to encode and distribute live feeds or do you think that it's still way too early and everything it's gonna be done in HEVC as rumours suggest?
I'm at the MC-IF meeting in Amsterdam at this very moment.

The current target completion date for the VVC spec is July 2020. There is no WAY it is going to be used in that summer's Olympics! HEVC transport is becoming common, particularly for 4K. We likely could see some VVC used for the 2024 summer Olympics. Even the 2022 Winter Olympics might be too soon for any mission critical applications.

We generally see new codecs used in IP services and VOD first. Breaking the Olympics for 10 minutes is about the highest-risk thing in the TV industry; people will start small.

[FranceBB]

I see, so probably 2024... Thank you for the info! :)
I really wanted to go to Amsterdam, but they didn't let me go to the IBC (I'm sitting in front of my desk in a studio right now 'cause I'm working).
The boss of my boss of my boss of my boss is there; as a matter of fact, I'm just a level 4 out of 10 in the company I work for, so it's normal. xD

[LigH]

https://www.cosgan.de/images/smilie/musik/c035.gif Komm, wir fahren nach Amsterdam...

I don't mind improving the future already today. I remember how I joined the doom9 forums in the middle of the DVD era. Working in an authoring studio. Who cares about DVD's anymore today?

[soresu]

The current target completion date for the VVC spec is July 2020. There is no WAY it is going to be used in that summer's Olympics! HEVC transport is becoming common, particularly for 4K. We likely could see some VVC used for the 2024 summer Olympics. Even the 2022 Winter Olympics might be too soon for any mission critical applications.



I just saw an announcement from Beamr about 8K HEVC encoding at 79 fps, sounds like they have it in the bag - I wonder if they are using SVT at all?

Edit: Found a PDF release from AMD about it, seems their new 64 core EPYC chip managed it. Link here (https://www.amd.com/system/files/documents/EPYC-7002-Beamr-Real-Time-8Kp60-HEVC-Encoding.pdf).

[Jamaika]

https://www.cosgan.de/images/smilie/musik/c035.gif Komm, wir fahren nach Amsterdam...

I don't mind improving the future already today. I remember how I joined the doom9 forums in the middle of the DVD era. Working in an authoring studio. Who cares about DVD's anymore today?

I buy a DVD and I will have it for a long time. Bluray is too expensive for me. How will the Euro, Bluray be even more expensive in Central Europe. 15 PLN / 60 PLN

Rumor has it that being in India you can buy in sacks. The problem is with the specification.

Interesting that there are no 4K movies on a pendrive or microSD.:D

[LigH]

Movies on electronic memory devices would be interesting, indeed. But the first concern of content producers would be copy protection. Surely they would have to use some [EP]ROM chip technology (which may have a slower read speed) and would have to store partially encrypted content with a technology that would rely on a "more or less secret" set of keys, not much different to DVD Video and Blu-ray encryption. At least I am quite sure that the AVCHD media and directory specs are widely compatible to UDF on Blu-ray.

[iwod]

I'm at the MC-IF meeting in Amsterdam at this very moment.

.

Any more news to share ? :):)

[benwaggoner]

Interesting that there are no 4K movies on a pendrive or microSD.:D
I've certainly used those for testing full-length 4K movies.

[benwaggoner]

Any more news to share ? :):)
VVC is very technically promising. We saw some comparisons of HEVC at 2x the bitrate of VVC, and VVC has more natural looking motion artifacts. As with the last 20 years of codec development, newer codecs tend to just lose detail instead of showing blocking/ringing at high QP. VVC > HEVC > H.264 > VC-1 > MPEG-2/H.263 in this regard.

HEVC licensing is quite confusing, particularly because not all licensors even publicly publish what use cases they are even licensing for.

VVC is unlikely to succeed unless that patent licensing is clearer than for HEVC. And it will have a lot more patents.

That was the general consensus.

[Jamaika]

New VVC codec v6.1 27.09.2019
#proposal JVET_O0245_VPS_DPS_APS 1 // JVET-O0245: constraints for VPS, DPS, and APS
#proposal JVET_O0044_MULTI_SUB_PROFILE 1 // JVET-O0044: Zero or more sub profile fields
#define JVET_O0143_BOTTOM_RIGHT_BRICK_IDX_DELTA 1 // JVET-O0143: Remove signaling of top_right_brick_idx
#define JVET_O0236_PPS_PARSING_DEPENDENCY 1 // JVET-O0236: Resolves a PPS parsing dependency
#define JVET_O0148_NUM_ACTIVE_REF_PIC_CHECK 1 // JVET-O0148: Constraint that num active entries in RPL 0 and RPL 1 for P and B pictures
#define JVET_O0145_ENTRYPOINT_SIGNALLING 1 // JVET-O0145: Not signalling num_entry_point_offsets but derive it at decoder
#define JVET_N0494_DRAP 1 // JVET-N0494: Dependent random access point indication SEI
#define JVET_O0173_O0176_O0338_NUMBRICK_M2 1 // JVET-O0173, O0176, O0338 : Replacing num_brick_rows_minus1 with num_brick_rows_minus2
#define JVET_OO152_BP_SEI_GDR 1 // JVET-O0152: Allowing association of a buffering period SEI with GDR picture
#define JVET_OO147_LEADING_PIC_CHECKING 1 // JVET-O0147: Constraints on leading pictures
#define JVET_O0299_APS_SCALINGLIST 1 // JVET-O0299: Scaling List Matrices Support in APS
#proposal JVET_O0625_ALF_PADDING 1 // JVET-O0625/O0654/O0662: Unified padding method in ALF
#define JVET_O0238_PPS_OR_SLICE 1 // JVET-O0238: Signal certain parameters either in PPS or per slice
#define SUPPORT_FOR_RECT_SLICES_WITH_VARYING_NUMBER_OF_TILES 1
#proposal JVET_O0452_PPS_BRICK_SIGNALING_CONDITION 1 // JVET-O0452: brick_split_flag signaled as RowHeight > 1 and uniform_brick_spacing_flag signaled as RowHeight > 2
#define JVET_O0610_DETECT_AUD 1 // JVET-O0610: detect presence of mandatory access unit delimiters
#define JVET_O0041_FRAME_FIELD_SEI 1
#define JVET_O0189_DU 1
#define JVET_N0353_INDEP_BUFF_TIME_SEI 1 // JVET-N0353 independent parsing of buffering and timing info SEIs
#proposal JVET_N0867_TEMP_SCAL_HRD 1 // JVET-N0867 temporal scalability support for HRD in buffering period and picture timing SEIs
#define JVET_N0100_PROPOSAL1 1 // JVET-N0100: ltrp picture signalling
#define JVET_N0865_SYNTAX 1 // JVET_N0865 syntax elements
#define JVET_N0865_NONSYNTAX 1 // JVET_N0865 other than syntax parts
#define JVET_N0865_GRA2GDR 1 // Changing the name of GRA to GDR
#define JVET_O0178 1 // JVET_O0178 - conditionally signal sps_sub_layer_ordering_info_present_flag
#define RPL_IN_IDR_FIX 1 // JVET_N0865 syntax elements
#define JVET_O0179 1 // JVET_O0179: Implement NAL unit header syntax proposal B
#define JVET_O0176_PROPOSAL3 1 // JVET_O0176 check for rect_slice_flag
#proposal JVET_O0177_PROPOSAL2 1 // JVET_O0177 Proposal2: conditionally signal num_units_in_tick and time_scale
#proposal JVET_O0177_PROPOSAL1 1 // JVET_O0177 proposal 1: Allow signaling of HRD parameters for temporal sub-layers optionally controlled by a flag
#define JVET_O0181 1 // JVET_O0181: non_reference_picture_flag
#delete HEVC_SEI 0 // SEI messages that are defined in HEVC, but not in VVC
#delete JVET_O0280_SIMD_TRIANGLE_WEIGHTING 0 // JVET-O0280: SIMD implementation for weighted sample prediction process of triangle prediction mode
#delete SIMD_ENABLE 0

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

[LigH]

Unfortunately, VVC doesn't compile well under MSYS2/MinGW with GCC 9.2.0 due to some questionable interpretation of logic. A patch (https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/merge_requests/974) is pending...

PS: May be merged now.

[soresu]

VVC is unlikely to succeed unless that patent licensing is clearer than for HEVC. And it will have a lot more patents.



That's a low bar to clear, for a start I'd say a single licensing body needs to be the maximum for VVC.

Greed and stupidity won out over the propagation of the HEVC standard before it even hit critical mass when they diverged into separate licensing groups.

It is foolishness to get this far in development without drawing up some sort of development participation agreement that prevents such licensing body schisms.

Whatever mistakes AOM made, they certainly got that part right at the start, and the proprietary actors like MPEG should have learned from their previous mistakes by now.

[Jamaika]

Unfortunately, VVC doesn't compile well under MSYS2/MinGW with GCC 9.2.0 due to some questionable interpretation of logic. A patch (https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/merge_requests/974) is pending...

PS: May be merged now.
A bit improved, some new patches added, but generally a lot of bugs. This is just Jamaica's fun. ;)
Of course there is conflict between POSIX thread and LINUX pthread. Let's not talk about Windows 64bit. GCC libgomp is very old 32bit and isn't in C++. So VVC isn't multithreads or parallelism.

Open source for maniac
https://www.sendspace.com/file/swnt07

Add new info video
VVCSoftware: VTM Encoder Version 6.1 [Windows][GCC 9.2.1][64 bit] [SIMD=NONE]
VVCSoftware: HDRTools Version 0.19.1 [SPLIT_PARALLEL (6 jobs)] [WPP_PARALLEL][OMP: WAIT_POLICY=,THREAD_LIMIT=]

Input real format & framerate : 1280x720 25.000Hz
Input pixel format & bitdepth : yuv420p8le
Input signal type :
Input color space / primaries : BT709 / Undef
Input color range : limited
Frame/Field : Frame based coding
Frame index : 0 - 999 (1000 frames)
Profile : next

[benwaggoner]

That's a low bar to clear, for a start I'd say a single licensing body needs to be the maximum for VVC.

Greed and stupidity won out over the propagation of the HEVC standard before it even hit critical mass when they diverged into separate licensing groups.

It is foolishness to get this far in development without drawing up some sort of development participation agreement that prevents such licensing body schisms.

Whatever mistakes AOM made, they certainly got that part right at the start, and the proprietary actors like MPEG should have learned from their previous mistakes by now.
The challenge is that MPEG itself doesn't do the patent licensing stuff; just the spec. There are disclosure rules in MPEG to minimize submarine patents. MPEG-LA is an entirely separate group from MPEG, and there is no mechanism to require licensors to use MPEG-LA in any case.

There's definitely a lot of talk about how MPEG could more proactively avoid later patent licensing nightmares, and it's been broadly stated that if VVC fails due to patent licensing issues, it will have been the last codec to use the traditional MPEG standards process. MPEG-5/EVC is an attempt to use a much more AOM like process within MPEG.

AOM was definitely very proactive in avoiding patent issues (at presumably tremendous expense in patent attorney hours). And the good news for AV2 is that more and more patents are expiring every year.

[Jamaika]

New VVC codec v6.2 10.10.2019
#proposal JVET_O0549_ENCODER_ONLY_FILTER 1 // JVET-O0549: Encoder-only temporal filter, no decoder changes
#proposal JVET_O0235_NAL_UNIT_TYPE_CONSTRAINTS 1 // JVET-O0235: NAL unit type constraints

VVCSoftware: VTM Encoder Version 6.2 [Windows][GCC 10.0.0][64 bit][SIMD=NONE]
VVCSoftware: HDRTools Version 0.19.1
VVCSoftware: libgomp / pthreads 32bit : 1.0 / 3.0 [SPLIT_PARALLEL (6 jobs)][WPP_PARALLEL][OMP: WAIT_POLICY=,THREAD_LIMIT=]
https://www.sendspace.com/file/qw7wc0

Added percentage indicator: :)
░░0.100% POC 0 TId: 0 ( I-SLICE, QP 20 ) 774928 bits [Y 46.4590 dB U 51.3664 dB V 52.9577 dB][ET 250 ][L0 ][L1 ]

[FranceBB]

Added percentage indicator: :)


Thank you for that! I was waiting for it. :)
I'm gonna run another test soon.

EDIT: New test. Slow, as it's using only 1 core, however at least now I have a percentage.
I'm gonna leave it running for hours this time; let's see how long it's gonna take to encode a few frames in 4K 25fps progress 4:2:2 planar 10bit...


EncoderApp.exe --SummaryVerboseness -c "encoder_randomaccess_vtm.cfg" --InputFile=lossless.yuv --BitstreamFile=slomo4ktest.vvc --SourceWidth=3840 --SourceHeight=2160 --FrameRate=25 --InputBitDepth=10 --InternalBitDepth=10 --OutputBitDepth=10 --MSBExtendedBitDepth=10 --InputChromaFormat=422 --ChromaFormatIDC=422 --ConformanceWindowMode=1 --FramesToBeEncoded=2734 --AspectRatioInfoPresent=1 --VideoSignalTypePresent=1

pause


https://i.imgur.com/71CCA0E.png
https://i.imgur.com/RsBbjBF.png
https://i.imgur.com/h7ShIov.png

[Jamaika]

You remember about added function the SIMD = SSE41/SSE42/AVX/AVX2 for test codec SIMD. Otherwise SIMD is ignored.
I have improved these functions by default on SIMD codecs.
https://www.sendspace.com/file/l8udsu
I don't know why AVX2 doesn't works with mavx2. There are many descriptions that GCC doesn't work with AVX2 under Windows. Codec AVX2 works with additional functions. I don't know them.
Waiting for the next update 360, the current codec doesn't work.
As much as I could improve.

[FranceBB]

After a whopping 13 hours of encoding, here's the sample (Slowmotion in 4K 3840x2160 10bit BT709 SDR 100 nit Limited Tv Range 64-940 25fps progressive) - Link (https://we.tl/t-nh3WxnbWmB)

[LigH]

Off topic: I like your meme 3

[Jamaika]

New VVC codec v7.0rc1 02.11.2019
#define JVET_P01034_PRED_1D_SCALING_LIST 1 // JVET-P1034: 1D Scaling list index and add predictor mode
#define JVET_P0345_LD_GOP_8 1 // JVET-P0345: low-delay gop size 8
#define JVET_P0371_CHROMA_SCALING_OFFSET 1 // JVET-P0371: Signalling offset for chroma residual scaling
#define JVET_P0803_COMBINED_MIP_CLEANUP 1 // JVET-P0803: Several MIP cleanups
#define JVET_P0199_P0289_P0303_MIP_FULLMATRIX 1 // JVET-P0199/P0289/P0303: Full matrix multiplication for all MIP block shapes
#define JVET_P0350_LFNST_IDX_CTX 1 // JVET-P0350: Add one context for LFNST idx coding
#define JVET_P0641_REMOVE_2xN_CHROMA_INTRA 1 // JVET-P0641: removing 2xN chroma intra blocks
#define JVET_P0206_TMVP_flags 1 // JVET-P0206: Signalling TMVP usage (remove pps TMVP idc and constraint when RPR is used)
#define JVET_P0599_INTRA_SMOOTHING_INTERP_FILT 1 // JVET-P0599: Cleanup of interpolation filtering for intra prediction
#define JVET_P1026_MTS_SIGNALLING 1 // JVET-P1026: CU level MTS signalling
#define JVET_P0571_FIX_BS_BDPCM_CHROMA 1 // JVET-P0571: align boundary strength for Chroma BDPCM
#define JVET_P0983_REMOVE_SPS_SBT_MAX_SIZE_FLAG 1 // JVET-P0983/JVET-P0391: Remove sps_sbt_max_size_64_flag
#define JVET_P0530_TPM_WEIGHT_ALIGN 1 // JVET-P0530: align chroma weights with luma weights for TPM blending
#define JVET_P0615_CHROMAMODE_CLEANUP 1 // JVET-P0615: intra chroma mode coding cleanup
#define JVET_P0667_QP_OFFSET_TABLE_SIGNALING_JCCR 1 // JVET-P0667: removing signaling of qp offset table for JCCR, at SPS and PPS, when JCCR is disabled.
#define JVET_P1000_REMOVE_TRANFORMSHIFT_IN_TS_MODE 1 // JVET-P1000: Remove Transformshift in TS mode
#define JVET_P0090_32BIT_MVD 1 // JVET-P0090: Limitation of abs_mvd_min2 binarization within 32-bit
#define JVET_P0298_DISABLE_LEVELMAPPING_IN_BYPASS 1 // JVET-P0298: Disable level mapping in bypass mode
#define JVET_P0347_MAX_MTT_DEPTH_CONSTRAINT 1 // JVET-P0347: Max MTT Depth constraint
#define JVET_P0325_CHANGE_MERGE_CANDIDATE_ORDER 1 // JVET-P0325: reorder the spatial merge candidates
#define JVET_P1018_IBC_NO_WRAPAROUND 1 // JVET-P1018: Disable reference sample wrapping around
#define JVET_P0406_YUV_FMT_GENERALIZATION_LDT 1 // JVET-P0406: Generalization of local dual tree (LDT) for different YUV formats
#define JVET_P0578_MINIMUM_CU_SIZE_CONSTRAINT 1 // JVET-P0578: minimum CU size constraint
#define JVET_P0091_REMOVE_BDOF_OFFSET_SHIFT 1 // JVET-P0091: Align sample offset calculation of BDOF and PROF
#define JVET_P0512_SIMD_HIGH_BITDEPTH 1 // JVET-P0512: MC SIMD support for high internal bit-depthf
#define JVET_P0491_BDOFPROF_MVD_RANGE 1 // JVET-P0491: clip the MVD in BDOF/PROF to [-31 31]
#define JVET_P0460_PLT_TS_MIN_QP 1 // JVET-P0460: Use TS min QP for Palette Escape mode
#define JVET_P1001_DEBLOCKING_CHROMAQP_FIX 1 //JVET-P1001/P1002: Align Chroma QP used in deblocking with the one used in Transform/invTransform
#define JVET_P0092_SMVD_SPEED_UP 1 // JVET-P0092: SMVD speed-up
#define JVET_P0043_DEBLOCKING_CLEANUP 1 // JVET-P0043: Fix deblocking design inconsistency in the affine and TPM mode
#define JVET_P0273_MTSIntraMaxCand 1 // JVET-P0273: Use MTSIntraMaxCand if LFNST is used
#define JVET_P0057_BDOF_PROF_HARMONIZATION 1 // JVET-P0057: harmonization of BDOF and PROF on motion refinement precision
#define JVET_P0653_BDOF_PROF_PARA_DEV 1 // JVET-P0653/P0281: fixed shift operations for BDOF and PROF parameter derivation
#define JVET_P0400_REMOVE_SHARED_MERGE_LIST 1 // JVET-P0400: removeal of shared merge list
#define JVET_P0170_ZERO_POS_SIMPLIFICATION 1 // JVET-P0170: Simplification of deriving ZeroPos
#define JVET_P0058_CHROMA_TS 1 // JVET-P0058: Enable Transform skip for chroma
#define JVET_P0436_CQP_OFFSET_SIGNALLING 1 // JVET_P0436: CU chroma QP offset signalling consistent with VPDU and bugfix
#define JVET_P0505_ALF_CLIP_VALUE 1 // JVET-P0505: Modified non-linear ALF clipping value derivations
#define JVET_P0154_PROF_SAMPLE_OFFSET_CLIPPING 1 // JVET-P0154/P0094/P0172/P0413/P0518/P0281: Clip the PROF sample offset to 14-bit
#define JVET_P1023_DMVR_BDOF_RP_CONDITION 1 // JVET_P1023: Reference picture conditions in DMVR and BDOF
#define JVET_P0162_REMOVE_ALF_CTB_FIRST_USE_APS_FLAG 1 // JVET-P0162: Removal of alf_ctb_use_first_aps_flag
#define JVET_P0059_CHROMA_BDPCM 1 // JVET-P0059: Enable BDPCM for chroma
#define JVET_P0072_SIMPLIFIED_TSRC 1 // JVET-P0072: Simplified transform-skip residual coding
#define JVET_P0077_LINE_CG_PALETTE 1 // JVET-P0077: Line CG palette mode
#define JVET_P0164_ALF_SYNTAX_SIMP 1 // JVET-p0164: simplify alf syntax with method2
#define JVET_O0549_ENCODER_ONLY_FILTER 1 // JVET-O0549: Encoder-only temporal filter, no decoder changes
#define JVET_P0042_FIX_INTER_DIR_CTX 1 // JVET-P0042: Fix overlap in context between the bi-pred flag for 8x8 CUs and the L0/L1 flag for all size CUs
#define JVET_P0111_CHROMA_422_FIX 1 // JVET-P0422: Bug fix of chroma 422 intra mode mapping
#define JVET_P0063_LDT_SPLIT_FIX 1 // JVET-P0063: Fix local dual tree on BT/TT split conditions in inter coding region
#define JVET_P0329_PLANAR_SIMPLIFICATION 1 // JVET-P0329: simplify planar prediction by comparison removal
#define JVET_P0081_CHROMA_LONG_DEBLOCKING_FIX 1 // JVET-P0081: Apply asymmetric long tap deblocking (1 + 3) filter at horizontal CTB boundaries for Chroma
#define JVET_P0516_PLT_BINARIZATION 1 // JVET-P0516: PLT is always signaled when pred mode is euqal to 1 (intra mode)
#define JVET_P0562_TS_RESIDUAL_CODING_SIMP 1 // JVET-P0562: Fix the Rice parameter equal to 1 for the remainder of TS residual coding
#define JVET_P0385_UNIFIED_MV_ROUNDING 1
#define JVET_P0418_ALIGN_MLRP_CCLM 1 // JVET-P0418: Align MLRP with CCLM in terms of reference lines/columns
#define JVET_P0335_HDRCTC_CHANGE 1 // JVET-P0335: change of HDR PQ CTC: enable LMCS and use QPc table in P0335, and disable lumaDQP and WCGPPSOffset
#define JVET_P0158_ALIGN_ALF_VB 1 // JVET-P0158: Apply ALF VB on the bottom CTU row
#define JVET_P0152_REMOVE_PPS_NUM_SUBBLOCK_MERGE_CAND 1 // JVET-P0152: remove pps_five_minus_max_num_subblock_merge_cand_plus1
#define JVET_P0088_P0353_RPR_FILTERS 1 // JVET-P0088 and JVET-P0353 Filters to use for downsampling in RPR
#proposal JVET_P0202_P0203_FIX_HRD_RELATED_SEI 1 // JVET-P0202 and JVET-P0203: CPB timing for sub-layers with DU and parsing independency to SPS
#proposal JVET_P0243_SINGLE_BIT_DEPTH 1 // JVET-P0243: Single bitdepth for luma and chroma
#proposal JVET_P0244_SPS_CLEAN_UP 1 // JVET-P0244/P0429: SPS cleanup changes
#proposal JVET_O0235_NAL_UNIT_TYPE_CONSTRAINTS 1 // JVET-O0235: NAL unit type constraints
#proposal JVET_P0445_SUBBLOCK_MERGE_ENC_SPEEDUP 1 // JVET-P0445: encoder speed up for sub-block based merge candidate search
#proposal JVET_P0205_VPS_ID_0 1 // JVET-P0205: VPS ID zero in SPS means no VPS in bitstream
#proposal JVET_P0526_PLT_ENCODER 1 // JVET-P0526: PLT encoder improvement
#proposal JVET_AHG14_LOSSLESS 1 // TS with lossless support
#proposal JVET_P0588_SUFFIX_APS 1 // JVET-P0588/P0452: suffix APS NUT
https://www.sendspace.com/filegroup/qUhQ4DgamIwL0qJ%2B7YYu4g

[Jamaika]

New VVC codec v7.1 07.12.2019
https://www.sendspace.com/file/hnkw5y

[Jamaika]

VVC codec v7.3 25.11.2019 plus updates Jamaika
https://github.com/Jamaika1/libbpg_jvetvvc/commit/f5b1e85b2c5259674ec5303b3bcd570af3f08d40#diff-f7f0689fb9724e6a506311d5eb4ea000
https://www.sendspace.com/file/k0j3v0

[FranceBB]

VVC codec v7.3 25.11.2019 plus updates Jamaika
https://github.com/Jamaika1/libbpg_jvetvvc/commit/f5b1e85b2c5259674ec5303b3bcd570af3f08d40#diff-f7f0689fb9724e6a506311d5eb4ea000
https://www.sendspace.com/file/k0j3v0

Thanks! :)
As always, I'll test it as soon as I'll have time.

[nakTT]

VVC codec v7.3 25.11.2019 plus updates Jamaika
https://github.com/Jamaika1/libbpg_jvetvvc/commit/f5b1e85b2c5259674ec5303b3bcd570af3f08d40#diff-f7f0689fb9724e6a506311d5eb4ea000
https://www.sendspace.com/file/k0j3v0
Hi, how do I use it with a GUI? I mean something like MeGUI or any other way other than a command line. Thank you in advance.

[LigH]

There may be no known UI yet, as the whole project is quite experimental still, and full control over the encoding process requires a configuration file due to the amount and complexity of parameters. So it's only for users who can handle all that easily.

[Jamaika]

Every week the commands change in config. You add config as a preset and import commands.
EncoderApp_360.exe --SummaryVerboseness -c "encoder_randomaccess_vtm.cfg" --InputFile=video_yuv444inraw.yuv --BitstreamFile=video_1.vvc --SourceWidth=1920 --SourceHeight=1080 --FrameRate=29.970 --InputBitDepth=10 --InternalBitDepth=10 --OutputBitDepth=10 --MSBExtendedBitDepth=10 --InputChromaFormat=444 --ChromaFormatIDC=444 {--MatrixCoefficients=1 --InputColorPrimaries=-1 --LMCSSignalType=0 [SDR] or --MatrixCoefficients=9 --InputColorPrimaries=1 --LMCSSignalType=2 [HDR]} --Level=6.2 --ConformanceWindowMode=0 --FramesToBeEncoded=750 --BDPCM=1 --HashME=1 --IBC=1 --MaxCUWidth=16 --MaxCUHeight=16 --CTUSize=32 --QP=30

Level 8bit 420 FullHD 4.1
Level 8bit 420 VGA<>SVGA 3.1
Level 8bit 420 EGA 2.1
Level 8bit> 444 VGA> 6.2
Level 10bit 420 4K 5.1

Function crop:
CropOffsetLeft : 10
CropOffsetTop : 10
CropOffsetRight : -10
CropOffsetBottom : -10

VVC has GOP only 16, thread only one. I don't know but level probably isn't auto.

[Blue_MiSfit]

Can I get a suggested config for max compression efficiency (exercise all the coding tools) 1080p SDR? Fixed QP is fine.

[Jamaika]

New version 7.3 plus fix Jamaika plus updates 31.01.2020
#define JVET_O1143_SUBPIC_BOUNDARY 1 // treat subpicture boundary as piucture boundary
#define JVET_P0101_POC_MULTILAYER 1 // POC derivation for pictures in dependent layers
#define JVET_P0117_PROFILE_TIER_LEVEL_SCALABILITY 1 // JVET-P0117: profile, tier and level for VVC scalability
#define JVET_Q0042_VUI 1 // Modifications to VUI syntax
#define JVET_Q0054 1 // fix for long luma deblocking decision
#define JVET_Q0055_MTS_SIGNALLING 1 // JVET-Q0055: Check for transform coefficients outside the 16x16 area
#define JVET_Q0089_SLICE_LOSSLESS_CODING_CHROMA_BDPCM 1 // JVET-Q0089: RRC slice-level switch for lossless coding and one SPS flag for luma and chroma BDPCM.
#define JVET_Q0110_Q0785_CHROMA_BDPCM_420 1 // JVET-Q0110/Q0785: Enable chroma BDPCM for 420, separate contexts for chroma BDPCM and bug-fixes.
#define JVET_Q0114_CONSTRAINT_FLAGS 1 // JVET-Q0114: AHG9: A few more general constraints flags
#define JVET_Q0117_PARAMETER_SETS_CLEANUP 1 // JVET-Q0117: cleanups on parameter sets
#define JVET_Q0119_CLEANUPS 1 // JVET-Q0119: AHG12: Cleanups on signalling of subpictures, tiles, and rectangular slices
#define JVET_Q0121_DEBLOCKING_CONTROL_PARAMETERS 1 // JVET-Q0121: Add deblocking control parameters for Cb and Cr and extend the parameter ranges
#define JVET_Q0128_DMVR_BDOF_ENABLING_CONDITION 1 // JVET-Q0128: Cleanup of enabling condition for DMVR and BDOF
#define JVET_Q0147_JCCR_SIGNALLING 1 // JVET-Q0147: Conditional signaling of sps_joint_cbcr_enabled_flag based on ChromaArrayType
#define JVET_Q0150 1 // fix for ALF virtual horizontal CTU boundary processing
#define JVET_Q0155_COLOUR_ID 1 // JVET-Q0155: move colour_plane_id from PH to SH
#define JVET_Q0156_STSA 1 // JVET-Q0156: Enable inter-layer prediction for STSA
#define JVET_Q0249_ALF_CHROMA_CLIPFLAG 1 // JVET-Q0249: Cleanup of chroma clipping flags for ALF
#define JVET_Q0267_RESET_CHROMA_QP_OFFSET 1 // JVET-Q0267: Reset chroma QP offsets at the start of each chroma QP offset group
#define JVET_Q0293_REMOVAL_PDPC_CHROMA_NX2 1 // JVET-Q0293: Removal of chroma Nx2 blocks in PDPC
#define JVET_Q0297_MER 1 // JVET_Q0297: Merge estimation region
#define JVET_Q0353_ACT_SW_FIX 1 // JVET-Q0353: Bug fix of ACT
#define JVET_Q0420_PPS_CHROMA_TOOL_FLAG 1 // JVET-Q0420: add pps_chroma_tool_offsets_present_flag in PPS
#define JVET_Q0433_MODIFIED_CHROMA_DIST_WEIGHT 1 // modification of chroma distortion weight (as agreed during presentation of JVET-Q0433)
#define JVET_Q0444_AMVR_SIGNALLING 1 // JVET-Q0444: Conditional signaling of sps_affine_amvr_enabled_flag based on sps_amvr_enabled_flag
#define JVET_Q0446_MIP_CONST_SHIFT_OFFSET 1 // JVET-Q0446: MIP with constant shift and offset
#define JVET_Q0447_WP_PARAM_ESTIM 1 // JVET-Q0447: Add search iterations for method 2,3 and 4
#define JVET_Q0468_Q0469_MIN_LUMA_CB_AND_MIN_QT_FIX 1 // JVET-Q0468: add support of min Luma coding block size; JVET-Q0469: fix for signaling of Intra Chroma Min QT size
#define JVET_Q0471_CHROMA_QT_SPLIT_ON_HEIGHT 1 // JVET-Q0471: Chroma QT split
#define JVET_Q0480_RASTER_RECT_SLICES 1 // JVET-Q0480: Eliminate redundant slice height syntax when in raster rectangular slice mode (tile_idx_delta_present_flag == 0)
#define JVET_Q0481_PARTITION_CONSTRAINTS_ORDER 1 // JVET-Q0481: Ordering of partition constraints syntax elements in the SPS and PH
#define JVET_Q0483_CLIP_TMVP 1 // JVET-Q0483: Clip TMVP when no scaling is applied
#define JVET_Q0487_SCALING_WINDOW_ISSUES 1 // JVET-Q0487: Fix scaling window issues when scaling ratio is 1:1
#define JVET_Q0495_NLALF_CLIP_CLEANUP 1 // JVET-Q0495: Cleanup of clipping table for NL-ALF
#define JVET_Q0500_CCLM_REF_PADDING 1 // JVET-Q0500: Reference samples padding for CCLM
#define JVET_Q0501_PALETTE_WPP_INIT_ABOVECTU 1 // JVET-Q0501: Initialize palette predictor from above CTU row in WPP
#define JVET_Q0503_Q0712_PLT_ENCODER_IMPROV_BUGFIX 1 // JVET-Q0503/Q0712: Platte encoder improvement/bugfix
#define JVET_Q0512_ENC_CHROMA_TS_ACT 1 // JVET-Q0512: encoder-side improvement on enabling chroma transform-skip for ACT
#define JVET_Q0516_MTS_SIGNALLING_DC_ONLY_COND 1 // JVET-Q0516/Q0685: disable MTS when there is only DC coefficient
#define JVET_Q0517_RPR_AFFINE_DS 1 // JVET-Q0517: affine down-sampling filters for RPR
#define JVET_Q0695_CHROMA_TS_JCCR 1 // JVET-Q0695: Enabling the RD checking of chroma transform-skip mode for JCCR at encoder
#define JVET_Q0775_PH_IN_SH 1 // JVET-Q0755: Allow picture header in slice header
#define JVET_Q0784_LFNST_COMBINATION 1 // lfnst signaling, latency reduction and a bugfix for scaling from Q0106, Q0686, Q0133
#define JVET_Q0787_SUBPIC 1 // JVET-Q0787: fix subpicture location signalling
#define JVET_Q0795_CCALF 1 // Cross-component ALF
#define JVET_Q0806 1 // Geo related adoptions (JVET-Q0059, JVET-Q0077, JVET-Q0123, JVET-Q0188, JVET-Q0242_GEO, JVET-Q0309, JVET-Q0365 and JVET-Q0370)
#define JVET_Q0814_DPB 1 // JVET-Q0814: DPB capacity is based on picture units regardless of the resoltuion
#define JVET_Q0819_PH_CHANGES 1 // JVET-Q0819: Combination of PH related syntax changes
#define JVET_Q0820_ACT 1 // JVET-Q0820: ACT bug fixes and reversible ACT transform
#define FIX_INIT_RESET_BEFORE_DEBLOCK 1
https://www.sendspace.com/file/ag482y

[Blue_MiSfit]

This is amazing. I did some fixed QP tests at 1 Mbps 1080p SDR against x265 placebo, and the VVC version was dramatically better. All the DCT goo from HEVC was totally gone. Soft, yes, but actually watchable.

[iwod]

This is amazing. I did some fixed QP tests at 1 Mbps 1080p SDR against x265 placebo, and the VVC version was dramatically better. All the DCT goo from HEVC was totally gone. Soft, yes, but actually watchable.

How does it compare to AV1?

[Blue_MiSfit]

Still testing that :)

[FranceBB]

Hi, how do I use it with a GUI? I mean something like MeGUI or any other way other than a command line. Thank you in advance.

I don't think anyone made a GUI so far 'cause this whole thing is still a work in progress. Even the command line itself has a pretty "rudimental" (pass me this term) syntax as it takes lossless uncompressed inputs only and is completely different from x262/x264/x265.
Besides it's still not optimised to scale in a multi-threading environment and it also lacks decoding support by pretty much everything other than its internal decoder (decoder.exe).
It's really way too early, but it's definitely worth to have to test it and play with it.
Just don't expect GUIs and mainstream support to pop up out of nowhere.

(By the way, if there's a GUI or something I'd be extremely happy to be proven wrong. As a side note, I noticed that XP support was removed a few releases ago but I actually managed to make it run anyway, so it's just a flag/target in the compiler. @Jamaika... I think you should keep targeting XP for the x86 32bit version as the encoder is absolutely compatible. If you don't wanna do it for any reason, just let me know and I will release my patched XP compatible binaries. Oh and by the way, thank you very much indeed for this new release. :D ).

[Blue_MiSfit]

I did the same test with AV1. I got surprisingly similar results, at least in my initial test clip.

In still frame comparison I preferred the VVC version 100% of the time, but this changed a bit in motion. I still preferred the VVC most of the time, but I was often hard pressed to tell any differences, and I did prefer AV1 in a few cases.

I'm sure a lot of the final results in real world systems will depend heavily on psy tuning and AQ.

In this very quick unscientific test these codecs are clearly in the same ballpark, and way ahead of HEVC. I'm surprised by this, since the BBC report showed HEVC and AV1 basically neck and neck, and with VVC way ahead. They were doing a scientific PSNR analysis and I'm doing a quick and dirty subjective comparison though...

[Jamaika]

@Jamaika... I think you should keep targeting XP for the x86 32bit version as the encoder is absolutely compatible. If you don't wanna do it for any reason, just let me know and I will release my patched XP compatible binaries. Oh and by the way, thank you very much indeed for this new release. :D ).
In this very quick unscientific test these codecs are clearly in the same ballpark, and way ahead of HEVC. I'm surprised by this, since the BBC report showed HEVC and AV1 basically neck and neck, and with VVC way ahead. They were doing a scientific PSNR analysis and I'm doing a quick and dirty subjective comparison though...
I'm aware that my activities aren't professional. I'm not a computer scientist. I merged patches manually in CodeBlock a few hours and out of curiosity I tested what this codec has visual capabilities. It's pathetic because a professionalist does it in five minutes. Then the codec test. Detection of critical errors and irritation VVC developers. Was my volunteering helpful? I made the VVC makers laugh that I was using GCC. I remind you that recent versions of GCC8.0 aren't stable for VVC. GCC8 doesn't support functions without parentheses {}. As an amateur I do not know if the codec is x86 or x64. The only premise for x86 is the libgomp linux plugin. Opensource VVC is available, but who exactly is it for?
My conclusions. This isn't codec for a doom9 forum user with a cheap camera in hand. Converted video source by x262/x264/x265 and then by vvc makes no sense. This codec is made by professionals for specific TV company. The developers have some VVC quality tests BBC out there somewhere. Apparently it's not their company. Their product is targeted at television networks. Adding multi-threads is done in five minutes and isn't currently priority.

Is my codec suitable for testing? Hmmm... Added additions have not been approved by the main moderators. Some work will go into the trash. Many features and security features may not yet be related or subtracted. The corporation researches it on its own video analyzers.

[iwod]

I did the same test with AV1. I got surprisingly similar results, at least in my initial test clip.

In still frame comparison I preferred the VVC version 100% of the time, but this changed a bit in motion. I still preferred the VVC most of the time, but I was often hard pressed to tell any differences, and I did prefer AV1 in a few cases.

I'm sure a lot of the final results in real world systems will depend heavily on psy tuning and AQ.

In this very quick unscientific test these codecs are clearly in the same ballpark, and way ahead of HEVC. I'm surprised by this, since the BBC report showed HEVC and AV1 basically neck and neck, and with VVC way ahead. They were doing a scientific PSNR analysis and I'm doing a quick and dirty subjective comparison though...

If I remember correctly the AV1 used in BBC results were 1 pass results. ( Need to double check when I have time )

Oh well I guess it is game on then. EVE has shown you could push AV1 further with another 20% bitrate reduction at the expense of another 50% INCREASE in encoding time compared to libaom.

[Blue_MiSfit]

Yeah all my testing was 1 pass fixed QP, since benchmarking rate control is not fair at this point :)

I continue to be suspicious of EVE - I've never been able to evaluate it and I'm not the only one. Has anyone ever actually used EVE VP9 or AV1?

[hajj_3]

Yeah all my testing was 1 pass fixed QP, since benchmarking rate control is not fair at this point :)

I continue to be suspicious of EVE - I've never been able to evaluate it and I'm not the only one. Has anyone ever actually used EVE VP9 or AV1?

what i find suspicious is that it isn't included in the moscow state university comparison. Why would they not give them a copy of their encoders to do an unbiased comparisons with unless it isn't as good as they claim.

[benwaggoner]

what i find suspicious is that it isn't included in the moscow state university comparison. Why would they not give them a copy of their encoders to do an unbiased comparisons with unless it isn't as good as they claim.
Are there any available EVE encoded streams to evaluate yet? I've only seen Excel plots and screen shots.

[Jamaika]

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

New updates and commands :D
EncoderApp_360.exe --SummaryVerboseness -c "encoder_randomaccess_vtm_2.cfg" --InputFile=113.yuv --BitstreamFile=video_2.vvc --SourceWidth=1280 --SourceHeight=720 --FrameRate=25.000 --InputBitDepth=8 --InternalBitDepth=8 --OutputBitDepth=8 --MSBExtendedBitDepth=8 --InputChromaFormat=420 --ChromaFormatIDC=420 --ConformanceWindowMode=0 --FramesToBeEncoded=750 --MatrixCoefficients=1 --InputColorPrimaries=-1 --LMCSSignalType=0 --Level=4 --BDPCM=1 --Tier=main --HashME=1 --IBC=1 --MaxCUWidth=16 --MaxCUHeight=16 --CTUSize=32 --QP=28 --MaxBTLumaISlice=32 --MaxBTChromaISlice=32 --MaxBTNonISlice=32 --MaxTTLumaISlice=32 --MaxTTChromaISlice=32 --MaxTTNonISlice=32

EncoderApp_360.exe --SummaryVerboseness -c "encoder_randomaccess_vtm_2.cfg" --InputFile=111.yuv --BitstreamFile=video_1.vvc --SourceWidth=1280 --SourceHeight=720 --FrameRate=25.000 --InputBitDepth=10 --InternalBitDepth=10 --OutputBitDepth=10 --MSBExtendedBitDepth=10 --InputChromaFormat=422 --ChromaFormatIDC=422 --ConformanceWindowMode=1 --FramesToBeEncoded=750 --MatrixCoefficients=9 --InputColorPrimaries=1 --LMCSSignalType=2 --Level=6.2 --BDPCM=1 --Tier=high --HashME=1 --IBC=1 --MaxCUWidth=16 --MaxCUHeight=16 --CTUSize=32 --QP=28 --MaxBTLumaISlice=32 --MaxBTChromaISlice=32 --MaxBTNonISlice=32 --MaxTTLumaISlice=32 --MaxTTChromaISlice=32 --MaxTTNonISlice=32

#define JVET_Q0117_PARAMETER_SETS_CLEANUP 1 // JVET-Q0117: cleanups on parameter sets
#define JVET_Q0786_PTL_only 1 // JVET-Q0786: modifications to VPS syntax - PTL part only (signal PTL for single layer OLSs)
#define JVET_Q0203_MULTI_SLICE_IN_TILE 1 // JVET-Q0203: Signalling of multiple rectangular slices within a tile
#define JVET_Q0817 1 // JVET_Q0817: Remove the constraint on single_slice_per_subpic_flag
#define JVET_Q0244 1 // JVET-Q0244 Aspect 3: Signal the slice width(height) in tiles when the number of tile columns(rows) is greater than 1.
#define JVET_Q0246_VIRTUAL_BOUNDARY_ENABLE_FLAG 1 // JVET-Q0246: virtual boundary enable flag in the SPS.
#define JVET_Q0151_Q0205_ENTRYPOINTS 1 // JVET-Q0151 & JVET-Q0205: Make mandatory the tile offsets signalling and move the entropy_coding_sync_enabled_flag entry_point_offsets_present_flag syntax elements to the SPS from the PPS
#define JVET_Q0468_Q0469_MIN_LUMA_CB_AND_MIN_QT_FIX 1 // JVET-Q0468: add support of min Luma coding block size; JVET-Q0469: fix for signaling of Intra Chroma Min QT size

Below quality QP = 28 is visible blur of pixels

[Jamaika]

New VVC codec v8.0 26.12.2019 plus updates https://github.com/Jamaika1/libbpg_jvetvvc
https://www.sendspace.com/file/0l7su7

Any 4K photo test is unbelievable. Compression time lasts for one and a half hours of one frame I. The following example shows VVC Q28 CTU32 as 350kb.
https://imgsli.com/MTI1NDA

[Jamaika]

First video decoder VVC analyzer Q1 2020
https://vicuesoft.com/products/analyzer

[benwaggoner]

Any 4K photo test is unbelievable. Compression time lasts for one and a half hours of one frame I. The following example shows VVC Q28 CTU32 as 350kb.
https://imgsli.com/MTI1NDA
Wow, that's some very impressive image compression. 1.5 hours is completely nuts for a still image, though. Of course, with more interframe techniques applied to intraframe coding, it makes since IDRs will be relatively slower versus other frame types than before (as we saw with HEVC).

[Jamaika]

New codec JVET VVC 09.04.2020 UNTESTED
https://www.sendspace.com/file/e27jcx

[hajj_3]

https://bitmovin.com/compression-standards-vvc-2020/

A blog from 2 months ago that shows VVC is 35% more efficient in regards to PSNR than HEVC. Requires 1.7x more cpu than HEVC to decode and requires 10x more cpu than HEVC to encode.

[Jamaika]

https://bitmovin.com/compression-standards-vvc-2020/

A blog from 2 months ago that shows VVC is 35% more efficient in regards to PSNR than HEVC. Requires 1.7x more cpu than HEVC to decode and requires 10x more cpu than HEVC to encode.
For CTU128. This codec is only 32bit and has one thread core. Tested for 4K and 8K formats, but creators isn't currently developing speed cpu. Added my codecs don't have SIMD support.

[benwaggoner]

For CTU128. This codec is only 32bit and has one thread core. Tested for 4K and 8K formats, but creators isn't currently developing speed cpu. Added my codecs don't have SIMD support.
MPEG doesn't even try to make performant reference encoders. There's much less of an emphasis on perf than in libvpx or libaom, for example.

To the extent they get SIMD and other speedups, it's really just to make testing iterations fast enough to be practical to do during development.

[ksec]

Here is a recent paper [1] comparing VVC and HEVC along with AV1. Although it is using an ancient VTM 4.0. For the bitrate I care about ( which is sub 4Mbps ) it seems to be doing well at anywhere between -30 -40% in terms of PSNR and VMAF. These are reference encoder anyway so I think the stats are good enough for now.

They are using AOM AV1 0.1.0-9647-ga6fa0877f, I am not familiar with libaom build number? But 1.0 was released a long time ago, does anyone know what version does this represent?

Edit: The same presentation with updated results [2], the libaom used was basically initial AOM 1.0 release in 2018, the presentation included updated results with encoder from late 2019.


[1] https://arxiv.org/pdf/2003.10282.pdf

[2] https://aomedia.org/wp-content/uploads/2019/10/FanZhang_BristolUniversity.pptx

[benwaggoner]

Here is a recent paper [1] comparing VVC and HEVC along with AV1. Although it is using an ancient VTM 4.0. For the bitrate I care about ( which is sub 4Mbps ) it seems to be doing well at anywhere between -30 -40% in terms of PSNR and VMAF. These are reference encoder anyway so I think the stats are good enough for now.
Well, it's been well documented that each generation of MPEG codecs since at least H.264 shows bigger subjective quality improvements relative to PSNR and SSIM than the previous. And VMAF got baked into AV1 and libaom in some ways that appear to artifically inflate AV1 VMAF scores relative to actual subjective quality.

We've seen cases where even a 20% "advantage" in objective metric bd-curves can still wind up as a lower subjective ranking.

Bear in mind that VMAF is just machine learning trying to estimate subjective quality ratings based on some basic objective rankings per frame. But it was only trained on what it's been trained on. Since no one has ranked VVC versus AV1 artifacts in the training set, VMAF simply hasn't been exposed to those, and I am skeptical of its scores for novel codecs until there is an updated model trained on examples of the codecs in question.

We've seen VMAF provide lower scores when adaptive quantization is used in H.264 or HEVC even when subjective ratings improved.

VMAF is still the least-bad objective metric we've had, and much more useful than PSNR. And it's gotten successively better as new models have come out (which is why talking about "VMAF" without specifying a version number is dangerous, as the same video will have a different VMAF score with today's model than with older ones).

But it's far from reliable for novel codecs or psychovisual algorithms.

[benwaggoner]

They are using AOM AV1 0.1.0-9647-ga6fa0877f, I am not familiar with libaom build number? But 1.0 was released a long time ago, does anyone know what version does this represent?

Edit: The same presentation with updated results [2], the libaom used was basically initial AOM 1.0 release in 2018, the presentation included updated results with encoder from late 2019.


[1] https://arxiv.org/pdf/2003.10282.pdf

[2] https://aomedia.org/wp-content/uploads/2019/10/FanZhang_BristolUniversity.pptx
This is really a quite well done academic paper, with some useful information. In particular, it compares objective and subjective ratings so we can see what the gap is like with modern implementations, in Table VII. We can see that VMAF is the best, but still short of the 0.9 correlation where things are generally thought to become more reliable. It's close enough that I can imagine a future VMAF could hit that threshold.

I note some limitations that make extrapolation to real-world implementations quite limited.

It uses standard test sequences. Many encoders, particularly reference ones, have been trained and tuned on those sequences endlessly. Comparing with novel source lets us see what an encoder can do with frames it hasn't been specifically developed to encode well.
The comparison is done at fixed QP and fixed GOP, so no rate control, no VBV, no adaptive quantization, no adaptive IDR placement. So it's missing a lot of important facets of both encoders and codecs. For example, a key limitation of VC-1 was the relatively high overhead that adaptive QP signalling took relative to H.264. This kind of standard testing never would have discovered that.
LibAOM has a lot more performance optimization than the reference HEVC and VVC encoders. So the perf disadvantage of AV1 would be a lot worse in the abstract. But these are also doing full searches pretty much, so it's quite challenging to extrapolate how fast practical production encoders would be in terms of quality @ perf @ bitrate.

These are very typical limitations for academic research in this area, and there really aren't any obvious better ways to do these comparisons at these early stages of codec development.

But in the real world, differences between encoders are bigger than between codecs. Recall x264 beat libaom for a lot of real-world scenarios early on, and x265 can beat libaom for a lot right now, especially when encoding time is constrained. This is at least as much about the maturity of the encoder implementation than fundamental advantages/disadvantages of the bitstream syntax and features.

[hajj_3]

vvc vtm v8.1 out: https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/-/releases/VTM-8.1

[Jamaika]

https://nofilmschool.com/sites/default/files/styles/article_wide/public/vcc_logo.jpg?itok=dwTGuQka
https://nofilmschool.com/three-new-codecs-are-coming

I'm afraid this will be the last version this year. There is currently no interest in developing on the European market. :D

[hajj_3]

https://nofilmschool.com/sites/default/files/styles/article_wide/public/vcc_logo.jpg?itok=dwTGuQka
https://nofilmschool.com/three-new-codecs-are-coming

I'm afraid this will be the last version this year. There is currently no interest in developing on the European market. :D

I'm not sure what your post means? There won't be a vvc vtm 8.2 or 9.0 this year? What information do you have about no interest in developing it in europe?

[Jamaika]

If you analyze the VVC library, you can see how much the addition of new functions or major corrections has decreased. Now these are minor corrections for a month. This has good sides, but the project has stopped. There are hardly any European creators although the project is German. It also amazes me. Disinterest? Why do I complain? This project isn't for hobbyist only for TV corporation and I have the impression after the advertisement that it is far from being implemented.

[hajj_3]

If you analyze the VVC library, you can see how much the addition of new functions or major corrections has decreased. Now these are minor corrections for a month. This has good sides, but the project has stopped. There are hardly any European creators although the project is German. It also amazes me. Disinterest? Why do I complain? This project isn't for hobbyist only for TV corporation and I have the impression after the advertisement that it is far from being implemented.

It is supposed to be ratified this year so that would explain the lack of new features. Also there has been a covid19 shutdown over the past month. You are reading way too much into that. VVC delivers a huge bandwidth saving which is especially important for tv broadcasters using DVB-T2 and for streaming.

[Jamaika]

VVC delivers a huge bandwidth saving which is especially important for tv broadcasters using DVB-T2 and for streaming.
For me the codec will need graphics card with VVC 10bit support for streaming and we can work. It will take a while.

[hajj_3]

For me the codec will need graphics card with VVC 10bit support for streaming and we can work. It will take a while.

Most users of VVC will indeed be using hardware decoders, which is the same as AV1. Youtube doesn't stream in AV1 by default, you need to enable it in your settings. Phone apps don't use it by default either except for netflix at low resolutions.

[ksec]

There were lots of draft update in between Jan and March. So it is in the very final stage of the standard. VVC was suppose to be ratified by July, with first official release of the standard in Oct 2020. Judging from the way things are handled it doesn't seems COVID will cause any delay to the standard.

MC-IF on the other hand looks a little uncertain.

[IgorC]

Youtube doesn't stream in AV1 by default, you need to enable it in your settings.
Youtube have started to stream AV1 by default already some time ago.
I have default settings and Youtube frequently streams in AV1 https://www.youtube.com/testtube

[benwaggoner]

If you analyze the VVC library, you can see how much the addition of new functions or major corrections has decreased. Now these are minor corrections for a month. This has good sides, but the project has stopped. There are hardly any European creators although the project is German. It also amazes me. Disinterest? Why do I complain? This project isn't for hobbyist only for TV corporation and I have the impression after the advertisement that it is far from being implemented.
It is absolutely true that VVC is being designed for professional use, like in TV, streaming distribution of premium content, and all the industries and scenarios that went MPEG-2 -> H.264 -> HEVC. And it's getting a lot of support from the usual MPEG stakeholders (although some of those are contributing even more heavily to EVC).

I don't know why VVC wouldn't be any less hobbyist-friendly than other MPEG codecs, although, since the patent licensing issues don't really apply to home use. There are certainly a huge number of tools that allow for deep experimentation and tweaking like we saw in x264's development for H.264.

[benwaggoner]

Most users of VVC will indeed be using hardware decoders, which is the same as AV1.
I'd say AV1 is somewhat unique as it has a much stronger emphasis in use on web browers given Google and Mozilla are big supporters. We still don't have announced GPUs with AV1 for Win/Mac or high volume SoCs for mobile. The only HW decoders I know of are in a few high end TVs, as Google requires AV1 for 8K streaming.

[Jamaika]

For maniacs: jvetvvc v8.2 + little fixes
https://www.sendspace.com/file/g3uurw

https://www.multichannel.com/pr-feed/elecard-supports-vvc
https://www.allegrodvt.com/video-ip-compliance-streams/compliance-streams-validation-verification/h266-vvc-standard/
https://arxiv.org/abs/2003.10282
https://www.ibc.org/manage/2020-crunch-time-for-codecs/5569.article

Since VVC will require hardware implementations it will likely take at least a couple of years for initial adoption. It is also hard at this stage to predict the cost of the licence for VVC but everyone is keen to avoid a repeat of what happened with HEVC.

[benwaggoner]

Since VVC will require hardware implementations it will likely take at least a couple of years for initial adoption. It is also hard at this stage to predict the cost of the licence for VVC but everyone is keen to avoid a repeat of what happened with HEVC.
I don't know that it'll still be 2+ years. VVC is getting lots of input from SoC and other HW companies to make decoder implementation more performant and parallelizable than AV1 was. We had HEVC HW encoders in the wild in 2014, within a year of HEVC's final standard being approved.

[utack]

I don't know that it'll still be 2+ years. VVC is getting lots of input from SoC and other HW companies to make decoder implementation more performant and parallelizable than AV1 was. We had HEVC HW encoders in the wild in 2014, within a year of HEVC's final standard being approved.

But that was a time when we had actual progress in phones that cost $400, not when the $900 phones big feature was removing the headphone jack
I don't think either codec will spread as quickly as the previous ones

[FranceBB]

VVC delivers a huge bandwidth saving which is especially important for tv broadcasters using DVB-T2 and for streaming.

It does, however realistically speaking we're far from seeing an implementation in the broadcast world. If we go back way before this coronavirus madness happened, there were experiments about 8K workflows. After all, other companies were doing it as well and Japan even began to air in 8K recording things like documentaries or theater acts like they did in Milan, Italy at "la scala" (which is a very important theater). Anyway, long story short, there was a lot of confusion about this and about how we were going to do it ourselves as some people were saying that the new standard was supposed to be 8K 100fps progressive 12bit HDR in PAL and 120fps progressive in NTSC but we had a lot of doubts. Besides, we didn't even know how we could deliver that and with which color curve... This all reminded me of the very early tests with 4K HLG when we didn't have it implemented in the cameras yet (heck, there weren't even cameras with it) so we had to shoot live events in Log and then apply a matrix of linear transformation in real time in the studio before Encoding and airing which was madness.
Anyway, back to 8K.
There has always been a lot of confusion about how things were going to be but we couldn't rest cause Tokyo Olympics were getting closer and Japanese were 100% sure that they were going to shoot and air it in 8K thus providing an 8K feed to broadcasters who bought the rights. So we tried to do what we could with what we had available.

The plan:

Sony UHC-8300 cameras, different video servers and two teams.


The reason for these cameras is that they provide simultaneous 8K/4K/FULL HD streams in HDR
and SDR and you can choose between S-Log3, HLG and the plain old linear BT709. There's been quite a debate about doing simultaneous streams as I didn't quite agree. My suggestion was to get a single 8K HDR stream out of octal 12G-SDI in HLG and then downscale and frame convert it live to 4K and also downscale, frame convert and divide in fields (interlace) it live to FULL HD and apply a linear transformation with a LUT made ad hoc. They didn't like it, they said that I shouldn't bring back old arguments and that we've been over this again, so the plan they wanted to go for was to have different outputs from the camera and then two different teams working on the HDR HLG 4K/8K stream and the other working on the SDR FULL HD one like we do now for 4K/FHD events 'cause the idea is to get as much as possible from both technologies and NOT to penalize SDR viewers only because of HDR workflows since (believe it or not) they still make a big fat chunk of our viewers. Now comes the funny part: how are we going to encode it? H.266 is still at a very early stage and it's really not practical to use it (heck, the standard isn't defined yet and there are no hardware encoders for it), so what do we do? Go with H.265? Well that's... Impossible...
Although H.265 is the best thing we have, you gotta keep in mind that a master 8K stream is over 48 Gbit/s and if you wanna encode it live you gotta do it fast so you don't have much complexity anyway unless you wanna add a huge delay to your customers (and many live encoders are between 1 and 4 seconds but even if you set it to the maximum, they don't let you choose anything higher than 20 seconds which is a huge amount of time). So, even with H.265 set for live encoding at its best but with a reasonable delay we couldn't really get anything good out of it lower than 70 Mbit/s and if we push the delay really up we can squeeze it to around 50 Mbit/s but that's it, really, so the question is: how the hell are we going to air it?!
Sadly everything stopped because of COVID-19 now but this is to give you an overview on how things were going before this disease... Honestly, I have no idea about what Japanese wanted to do with the Olympics, but still...
I also heard that BTSport guys were ready to offer the Champion's League final in 8K HDR10+ PQ H.265 50fps but via internet only and not on their linear channels, which is reasonable considering that with internet you can overcome pretty much everything as long as you're willing to pay for the CDN bandwidth.
Now everything is frozen and we're in this limbo waiting for things to go back to normal: Olympics have been postponed for a year and we don't even know if there will be a Champion's League final this year as it becomes less and less likely as day passes...
This is all to say: we're not ready, but I'd very much like to see H.266 begin to be implemented in real hardware encoders and TV decoders...

[hajj_3]

I'm not sure why you would be using VVC for the olympics as there's no chance that consumers will have a tv or set-top box that can hardware decode VVC in time for the olympics. Or are you just referring to using it to transmit between different broadcast companies so that they can then encode the 8k in to h265 if they wanted? Most people aren't going to see the difference between 4k and 8k unless they are in a cinema.

[ksec]

But that was a time when we had actual progress in phones that cost $400, not when the $900 phones big feature was removing the headphone jack
I don't think either codec will spread as quickly as the previous ones

Well it doesn't change the fact we are still shipping ˜1.3B Smartphone annually. Apple, Samsung, Qualcomm, and Huawei together would be 90% of the SoC Market. You could expect close to 80% of Smartphone to have a hardware decoder within 4 year if the Big four act together.

That is all of course, assuming they dont repeat the stupid mistake of HEVC patent pool. ( Still pointing my anger at Qualcomm )

And if anyone like me is keeping an eye on MC-IF, things are *not* looking good.

[FranceBB]

I'm not sure why you would be using VVC for the olympics as there's no chance that consumers will have a tv or set-top box that can hardware decode VVC in time for the olympics. Or are you just referring to using it to transmit between different broadcast companies so that they can then encode the 8k in to h265 if they wanted? Most people aren't going to see the difference between 4k and 8k unless they are in a cinema.

We didn't want to, it was just a thought we had at the very beginning about how to air in 8K without compromising quality too much as it appeared clear that with H.265 it wasn't possible due to bandwidth and complexity limitations of real-time encoders... :(
I think we're still way behind with 8K productions and it's not gonna be a thing for quite some time...
So, in the end, it's not true that European broadcasters are not interested in VVC, Jamaika, it's just that it's way too early...

[Blue_MiSfit]

How would you have even done real-time 8k HEVC? Is there an encoder that supports this? Or would you have to do bonded 4k encoders like how the NHK guys always do their crazy demos?

[FranceBB]

How would you have even done real-time 8k HEVC? Is there an encoder that supports this? Or would you have to do bonded 4k encoders like how the NHK guys always do their crazy demos?

8 SDI 4K streams that go to 4 4K HEVC encoders bonded together.
There's no 8K HEVC hardware encoder yet, but if you are aware of one, please let me know.

[benwaggoner]

I'm not sure why you would be using VVC for the olympics as there's no chance that consumers will have a tv or set-top box that can hardware decode VVC in time for the olympics. Or are you just referring to using it to transmit between different broadcast companies so that they can then encode the 8k in to h265 if they wanted? Most people aren't going to see the difference between 4k and 8k unless they are in a cinema.
Most cinemas are still 2K, and even if it's a 4K projector with 4K content, almost all the VFX are still going to be 2K and upsampled. Any detail beyond 720p vanishes quickly with motion with 1/48th sec of motion blur.

And yes, no one was going to do VVC for the 2020 Olympics. Maybe there will be some tests for the now 2021 Olympics, but nothing customer facing. That would be like doing AV1 for 4K premium DRM content in 2020; HW DRM is vanishingly rare, and if an AV1 encoder can be coerced into doing even 4K live, the MIPS/pixel would be so low that a 1080p HEVC would probably look better below 25 Mbps.

[benwaggoner]

8 SDI 4K streams that go to 8 4K HEVC encoders bonded together.
There's no 8K HEVC hardware encoder yet, but if you are aware of one, please let me know.
It's 4 bonded together; 2x2 grid. Which means that the edges of the encodes are exactly a cross in the center of the screen, where even slight variations are going to be pretty darn obvious. To the extent that 8K works, it's because the extra detail is largely invisible and so averages out problems :sly:.

[foxyshadis]

And yes, no one was going to do VVC for the 2020 Olympics. Maybe there will be some tests for the now 2021 Olympics, but nothing customer facing.

The Olympics are awash in so much money that it's probably the ideal time to try every crazy thing you have on the backburner, though. They do usually get some mix of every mostly-impractical technology of the day to broadcast each time, along with the standard steams.

Not that, if it came together, VVC would be much more than a point-to-point broadcast between a custom camera and receiver, but such are the things PR Newswire is made of.

[benwaggoner]

We didn't want to, it was just a thought we had at the very beginning about how to air in 8K without compromising quality too much as it appeared clear that with H.265 it wasn't possible due to bandwidth and complexity limitations of real-time encoders... :(
Any concern you have with real-time encoders for HEVC is going to be at least 10x worse for VVC for a couple of years. It's more complex and hasn't had time for thorough optimization and speed/quality tuning.

I think we're still way behind with 8K productions and it's not gonna be a thing for quite some time...
So, in the end, it's not true that European broadcasters are not interested in VVC, Jamaika, it's just that it's way too early...
With Covid-19, I'm not aware of any actual 8K projects, live events or scripted, planned for 2020. While there were projects shooting in 8K, post production is all being done at 4K, often with many 2K elements. Now little is being shot with anything but webcams. And people working from home don't have access to 8K post workflows.

[birdie]

This is all to say: we're not ready, but I'd very much like to see H.266 begin to be implemented in real hardware encoders and TV decoders...

You're trying to solve a problem which doesn't yet exist and maybe won't exist ever. The number of 8K TV sets sold in the world to this date is less than a thousand I guess, maybe even less.

The more important issue is that the jump from FullHD to 4K was a huge one, outright perceivable as well, while 8K ... I don't want to say it's completely useless but you have to be sitting a foot away from a TV set to appreciate the picture quality and clarity. If you're in your usual sitting-room sitting six feet away or farther from your 60" TV set there will be zero difference between 4K and 8K streams.

8K has a place for medical personnel, civil engineers, CAD designers and for all the professions where utmost picture clarity is required but home entertainment is not one of them.

[benwaggoner]

You're trying to solve a problem which doesn't yet exist and maybe won't exist ever. The number of 8K TV sets sold in the world to this date is less than a thousand I guess, maybe even less.
It's a lot more than that. Analyst estimates are 2M will be sold in 2020.

The more important issue is that the jump from FullHD to 4K was a huge one, outright perceivable as well, while 8K ... I don't want to say it's completely useless but you have to be sitting a foot away from a TV set to appreciate the picture quality and clarity. If you're in your usual sitting-room sitting six feet away or farther from your 60" TV set there will be zero difference between 4K and 8K streams.
One foot away for each 10" diagonal is about right to resolve full 4K detail with 20/20 vision. Closer than that is where you could start to see 8K. Closer than that is also where the viewing angle to the left and right edges of the screen become so distorted it's hard to see what's happening, and largely outside of your perephrial vision.

8K has a place for medical personnel, civil engineers, CAD designers and for all the professions where utmost picture clarity is required but home entertainment is not one of them.
8K is great for when you can lean forward and move your head to "zoom in" to parts of the image. Computer monitors, gaming, collaborative screens, digital signage, etcetera. Just not leaning back and watching moving images without actively moving one's head or body.

Also, a pixel in a camera's Beyer pattern isn't the same as an encoded 4:2:0 pixel or 3-4 subpixels on a display. Having 12-16 subpixels per encoded pixel makes for better 8K than having just 3-4.

All that said, promises great improvements at every resolution. It's not tied to 8K.

[Jamaika]

New updates VVC
#define JVET_Q0488_SEI_REPETITION_CONSTRAINT 1 // JVET-Q0488: SEI repetition constraint
#define JVET_Q0764_WRAP_AROUND_WITH_RPR 1 // JVET-Q0764: Combination of wrap around offset and RPR
#define JVET_R0045_TS_MIN_QP_CLEANUP 1 // JVET-R0045: Cleanup for signalling of minimum QP of transform skip
#define JVET_R0059_RPL_CLEANUP 1 // JVET-R0059 aspect 2: Condition the signalling of ltrp_in_header_flag[ listIdx ][ rplsIdx ].
#define JVET_R0071_SPS_PPS_CELANUP 1 // JVET-R0071 item 2-4: cleanups on subpicture signalling (item 1 has been ported in JVET_R0156_ASPECT4)
#define JVET_R0090_VUI 1 // JVET-R0090: Fix parsing dependencies in VUI syntax
#define JVET_R0091_CONSTRAINT_SLICE_ORDER 1 // JVET-R0091: constraint slice signalling order to be the same as slice coding order
#define JVET_R0094_DPB_TID_OFFSET 1 // JVET-R0094: DPB output temporal ID offsets
#define JVET_R0097_MAX_TRSIZE_CONDITIONALY_SIGNALING 1 // JVET-R0097: Aspect 1, If the luma CTB size is not larger than 32, sps_max_luma_transform_size_64_flag is not signalled and inferred to be 0
#define JVET_R0098_LMCS_AND_SCALING_LISTS_FOR_PH_IN_SH 1 // JVET-R0098: Only signall LMCS and explicit scaling list enable flags in SH when PH is not in SH
#define JVET_R0100 1 // JVET-R0100: Proposal 1 DUI Signalling and inference
#define JVET_R0107_VPS_SIGNALING 1 // JVET-R017: Proposal 2 VPS signaling change and updated inference rule
#define JVET_R0108_DCI_SIGNALING 1 // JVET-R0108 Proposal 1 DCI signaling changes
#define JVET_R0103_DU_SIGNALLING 1 // JVET-R0103: Proposal 1 decoding unit signalling change
#define JVET_R0110_MIXED_LOSSLESS 1 // JVET-R0110: Slice level mixed lossy/lossless coding: encoder only method
#define JVET_R0113_AND_JVET_R0106_PPS_CLEANUP 1 // JVET-R0113 and JVET-R0106: Cleanup in Picture Parameter Set
#define JVET_R0114_NEGATIVE_SCALING_WINDOW_OFFSETS 1 // JVET-R0114: Allow negative scaling window offsets
#define JVET_R0130_TC_DERIVATION_BUGFIX 1 // JVET-R0130: Cleanup of tC derivation for deblocking filter
#define JVET_R0143_TSRCdisableLL 1 // JVET-R0143: disable TSRC for lossless coding
#define JVET_R0156_ASPECT3_SPS_CLEANUP 1 // Condition sps_sublayer_dpb_params_flag on sps_ptl_dpb_hrd_params_present_flag, in addition to sps_max_sublayer_minus1, JVET-R0156 proposal 3, JVET-R0170, JVET-R0222 proposal 2
#define JVET_R0156_ASPECT4_SPS_CLEANUP 1 // JVET-R0071 #1, R0156 #4, R0284 #1: Condition sps_independent_subpics_flag on "sps_num_subpics_minus1 > 0"
#define JVET_R0161_CONDITION_SIGNAL_PTL_IDX 1 // JVET_R0161 proposal 2: skip PTL index signaling when number of signaled PTL structure is equal to number of OLSs
#define JVET_R0165_OPTIONAL_ENTRY_POINT 1 // JVET-R0165: Optional entry point offset
#define JVET_R0166_SCALING_LISTS_CHROMA_444 1 // JVET-R0166: Scaling list for Chroma 444
#define JVET_R0185_OLS_DPB_CLEANUP 1 // JVET-R0185: Replace if( !vps_all_independent_layers_flag ) condition on vps_num_dpb_params syntax element with if(!each_layer_is_an_ols_flag)
// Change vps_num_dpb_params to vps_num_dpb_params_minus1 and change the semantics to a two-way constraint
// Signal DPB parameters for OLS in this case only if(!each_layer_is_an_ols_flag)
#define JVET_R0186_CLEANUP 1 // JVET-R0186 aspect 1: Signal the pps_no_pic_partition_flag ahead in the PPS.
#define JVET_R0188 1 // JVET-R0188: Signalling slice_width_in_tiles_minus1[i] and slice_height_in_tiles_minus1[i]
#define JVET_R0191_ASPECT3 1 // JVET-R0191#3: Modify the upper range of vps_num_dpb_params and num_ols_hrd_params_minus1 to be total number of OLSs minus the number of single-layer OLSs
// Constrain that each PTL, DPB, and HRD params in VPS are referred to at least once
#define JVET_R0200_MOVE_LMCS_AND_SCALING_LIST_SE 1 // JVET-R0200 Move the SH flags slice_lmcs_enabled_flag and slice_explicit_scaling_list_used_flag to be just after the ALF parameters
#define JVET_R0201_PREFIX_SUFFIX_APS_CLEANUP 1 // JVET-R0201 Cleanups on Prefix and Suffix APS
#define JVET_R0202_WHEN_PH_IN_SH_INFO_FLAGS_EQUAL_0 1 // JVET-R0202 When sh_picture_header_in_slice_header_flag is equal to 1, rpl_info_in_ph_flag, dbf_info_in_ph_flag, sao_info_in_ph_flag, wp_info_in_ph_flag, qp_delta_info_in_ph_flag shall be be equal to 0
#define JVET_R0202_WHEN_PH_IN_SH_NO_SUBPIC_SEPARATE_COLOR 1 // JVET-R0202 Add constraints when sh_picture_header_in_slice_header_flag equal to 1 sps_subpic_info_present_flag and separate_colour_plane_flag shall be equal to 0
#define JVET_R0203_IRAP_LEADING_CONSTRAINT 1 // JVET-R0203: Constraint that IRAP NAL unit type cannot be mixed with RASL_NUT / RADL_NUT
#define JVET_R0205 1 // JVET-R0205: Condition presence of inter_layer_ref_pics_present_flag on sps_video_parameter_set_id
#define JVET_R0208_ALF_VB_ROUNDING_FIX 1 // JVET-R0208: Rounding offset fix for ALF virtual boundary processing
#define JVET_R0210_NUMTILESINSLICE_SIGNALLING 1 // JVET-R0210 section 3.3: Don't signal NumTilesInSlice syntax element when numTilesInPic - slice_address is 1.
#define JVET_R0225_SEPERATE_FLAGS_ALF_CHROMA 1 // Use two separate flags (one for Cb, one for Cr) to replace ph_alf_chroma_idc in PH and sh_alf_chroma_idc in SH
#define JVET_R0232_CCALF_APS_CONSTRAINT 1 // JVET-R0232 section 3.2: APS contraint for CCALF
#define JVET_R0233_CCALF_LINE_BUFFER_REDUCTION 1 // JVET-R0233 method 2: Line buffer reduction for CCALF
#define JVET_R0247_PPS_LP_FTR_ACROSS_SLICES_FLAG_CLEANUP 1 // JVET-R0247: Skip pps_loop_filter_across_slices_enabled_flag when the picture contains one slice
#define JVET_R0266_DESC 1 // JVET-R0266: change the signalling of the PPS ID from ue(v) to u(6); Code virtual boundary positions using ue(v)
#define JVET_R0267_IDR_RPL 1 // JVET-R0267: Add RPL constraint for IDR picture
#define JVET_R0271_SLICE_LEVEL_DQ_SDH_RRC 1 // JVET-R0271/R0155: Slice level DQ and SDH granularity for mixed lossy/lossless.
#define JVET_R0275_SPS_PTL_DBP_HRD 1 // JVET-R0275: Modified constraint for sps_ptl_dpb_hrd_params_present_flag
#define JVET_R0276_REORDERED_SUBPICS 1 // JVET-R0276: reference picture constraint for reordered sub-pictures
#define JVET_R0277_RPL 1 // JVET-R0277: Modified condition for sh_num_ref_idx_active_override_flag, inference for sh_collocated_from_l0_flag equal to 1 for P-slices
#define JVET_R0278_CONSTRAINT 1 // JVET-R0278: ph_inter_slice_allowed_flag constraint
#define JVET_R0324_PH_SYNTAX_CONDITION_MODIFY 1 // JVET-R0324 add conditions on PH syntax to conder whether current pic is bi-predictive picture
#define JVET_R0327_ONE_PASS_CCALF 1 // JVET-R0327: One-pass CCALF
#define JVET_R0330_CRS_CLIP_REM 1 // JVET-R0330: Remove redundant clipping in chroma residual scaling factor derivation
#define JVET_R0332_HLS_ORDER 1 // JVET-R0332: Grouping syntax elements in SPS based on slice type
#define JVET_R0334_PLT_CLEANUP 1 // JVET-R0334: Disable chroma palette for local dual tree
#define JVET_R0347_MTT_SIZE_CONSTRAIN 1 // JVET-R0347: Set upper limit of minQtSize and maxTtSize to 64, set upper limit of maxBtSize to 64 in chroma-tree
#define JVET_R0350_MIP_CHROMA_444_SINGLETREE 1 // JVET-R0350: MIP for chroma in case of 4:4:4 format and single tree
#define JVET_R0371_MAX_NUM_SUB_BLK_MRG_CAND 1 // JVET-R0371: set the range of max number of subblock based merge candidate to 0 to 5 - sps_sbtmvp_enabled_flag.
#define JVET_R0380_SCALING_MATRIX_DISABLE_YCC_OR_RGB 1 // JVET-R0380 solution3-3: Disable scaling matrix for blocks coded in alternative colour space.
#define JVET_R0388_DBF_CLEANUP 1 // JVET-R0388: Cleanups on deblocking signalling
#define JVET_R0413_HRD_TIMING_INFORMATION 1 // JVET-R0413: HRD timing parameters signalling
#define JVET_R0437_BS_DERIVATION 1 // JVET-R0437: fix the bS derivation for palette mode
#define JVET_R0483_SH_TSRC_DISABLED_FLAG_CLEANUP 1 // JVET-R0483 Comb 4: R0049 + R0271, only R0049 method 3 aspect (Skip signaling sh_ts_residual_coding_disabled_flag when sps_transform_skip_enabled_flag = 0, also proposed in R0068, R0097, R0142, R0153) as R0271 has its own macro
#define JVET_R0164_MEAN_SCALED_SATD 1 // JVET-R0164: Use a mean scaled version of SATD in encoder decisions
https://github.com/Jamaika1/libbpg_jvetvvc
test codec VVC with gcc 11.0 C++11
https://www.sendspace.com/file/vqahm6

[ksec]

https://thebroadcastknowledge.com/2020/05/11/video-versatile-video-coding-vvc/#video

An article, and video on the current state of VVC. And it really is promising in terms of Complexity to Performance Ratio.

VVC, Finger crossed.

[ksec]

VTM 9.0 is out.

https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/-/releases

[LigH]

Will it compile in GCC 10.1? ... To be tested.

[Jamaika]

test codec VVC 9.0 280512020 with gcc 11.0 C++11
https://www.sendspace.com/file/om1sw8

[benwaggoner]

test codec VVC 9.0 280512020 with gcc 11.0 C++11
https://www.sendspace.com/file/om1sw8
Wow, I see 1431 command line parameters! That's got to be a record...

[Jamaika]

Will it compile in GCC 10.1? ... To be tested.
GCC win32 doesn't distinguish between definitions. For defines X equal zero this result is '#if defined (X)' one. Troublesome for WIN64 and _WIN64.
For GCC win32 is 'Memory allocation failed: std::bad_alloc'. For GCC win64 is correct.
For GCC win32 is:
c:\msys1000\lib\gcc\i686-w64-mingw32\10.1.0\include\xmmintrin.h:892:1: error: inlining failed in call to 'always_inline' '__m128 _mm_set1_ps(float)': target specific option mismatch
892 | _mm_set1_ps (float __F)
| ^~~~~~~~~~~
ResizeBiCubic.cpp:150:29: note: called from here
150 | __m128 rb3 = _mm_set1_ps(beta[3]);
| ~~~~~~~~~~~^~~~~~~~~
For GCC win64 is correct.
Why am I using gcc win64? Because I can test the codec.
Wow, I see 1431 command line parameters! That's got to be a record...
I don't know what the problem is.

[benwaggoner]

I don't know what the problem is.
No problem per se, but rather remarkable!

It'll take a while to figure out optimal presets and tunings given all those options. But that's true of every new codec generation.

[LigH]

There will not be any more recent VVC build made with MABS, because the JVET team does not spend any time (https://jvet.hhi.fraunhofer.de/trac/vvc/ticket/1072#comment:2) to make it support GNU C++ 10, especially not in MSYS2/MinGW. Any idea to solve the recent compiling issue (https://github.com/m-ab-s/media-autobuild_suite/issues/1663) will be appreciated.

[benwaggoner]

There will not be any more recent VVC build made with MABS, because the JVET team does not spend any time (https://jvet.hhi.fraunhofer.de/trac/vvc/ticket/1072#comment:2) to make it support GNU C++ 10, especially not in MSYS2/MinGW. Any idea to solve the recent compiling issue (https://github.com/m-ab-s/media-autobuild_suite/issues/1663) will be appreciated.
Someone just uploaded a proposed patch for this!

[Jamaika]

I don't know programming, but gcc doesn't like converting int to uint32_t or unsigned.
The problem is with uint32_t uiArrayAddr = cnt. Earlier in UnitTools it is unsigned. GCC only tolerates int. I don't know if this is a software error.
https://github.com/Jamaika1/libbpg_jvetvvc

[`Orum]

I've been trying to encode images with VTM for some time now, but without success. Does anyone know what the secret is to getting the encoder to actually encode single-frame video, i.e. images, is? Here's what I've been trying to so far (width/height hard coded for the time being):

ffmpeg -i $1 -pix_fmt yuv420p12le -r 10 -strict -1 $1.yuv
EncoderApp -i $1.yuv -wdt 4272 -hgt 2848 -fr 10 -f 1 -g 1 --InputBitDepth=12 -b $1.h266

When I run this I get:
Error: found fewer Reference Picture Sets than GOPSize
Error: Invalid GOP structure given

[benwaggoner]

I've been trying to encode images with VTM for some time now, but without success. Does anyone know what the secret is to getting the encoder to actually encode single-frame video, i.e. images, is? Here's what I've been trying to so far (width/height hard coded for the time being):

ffmpeg -i $1 -pix_fmt yuv420p12le -r 10 -strict -1 $1.yuv
EncoderApp -i $1.yuv -wdt 4272 -hgt 2848 -fr 10 -f 1 -g 1 --InputBitDepth=12 -b $1.h266

When I run this I get:
Error: found fewer Reference Picture Sets than GOPSize
Error: Invalid GOP structure given
You may need to set the equivalent of --keyint 1 --bframes 0 to tell the encoder not to try to get extra frames to determine GOP structure.

I'd probably use a frame rate of 1 as well.

[`Orum]

set the equivalent of --keyint 1 --bframes 0
The equivalent of the former seems to be either -ip 0 or -ip 1, I'm not sure which is correct. I couldn't find a way to disable B-frames, but this seems to be as poorly documented as aomenc, though with far more parameters. In any case, setting -ip to either of those alone still gives me the "Invalid GOP structure" error.

Also, I was using a higher frame rate as it was complaining with some other combination of parameters (I don't recall exactly what, as I've tried countless things) that my framerate wasn't > 1 FPS.

[benwaggoner]

Ah, reference encoders. Is there an explicit still picture mode, maybe? That's got the longest --fullhelp I've ever seen.

[foxyshadis]

Ah, reference encoders. Is there an explicit still picture mode, maybe? That's got the longest --fullhelp I've ever seen.

Holy cow, you were not kidding.

Something in there caught my eye, though: A "Mixed Lossy Lossless" setting. This is my primary use case for HEIF/AVIF, which are more like a single-page PDF, if anyone would bother to support that; if this makes it into the final codec it'll mean desktop shared streams don't have to be absolute garbage in order to also show sections that can't be efficiently losslessly compressed.

[Jamaika]

ffmpeg.exe -loglevel error -i "output1.png" -an -f rawvideo -frames 1 -vf scale=1564:1558:in_color_matrix=rgb:in_range=full:out_color_matrix=bt2020nc:out_range=full,format=yuv420p10le 113.yuv
EncoderApp_360.exe --SummaryVerboseness --InputFile=113.yuv --BitstreamFile=video_2.vvc --SourceWidth=1564 --SourceHeight=1558 --FrameRate=25.000 --InputBitDepth=10 --OutputBitDepth=10 --MSBExtendedBitDepth=10
--MatrixCoefficients=9 --InputColorPrimaries=1 --LMCSSignalType=2 --ConformanceWindowMode=1 --FramesToBeEncoded=1 --HashME=1 --IBC=1
--DecodingRefreshType=1 --Profile=auto --InputSampleRange=1 --AspectRatioInfoPresent=1 --ChromaLocInfoPresent=1
--MaxCUWidth=16 --MaxCUHeight=16 --CTUSize=32 --MaxBTLumaISlice=32 --MaxBTChromaISlice=32 --MaxBTNonISlice=32 --MaxTTLumaISlice=32 --MaxTTChromaISlice=32 --MaxTTNonISlice=32
--CostMode=lossy --InputChromaFormat=420 --ChromaFormatIDC=420 --QP=28 --BDPCM=0 --ColorTransform=0 --VideoFullRange=0 --ChromaTS=1 --DepQuant=1 --LMCSEnable=1 --RDOQ=1 --RDOQTS=1 --SBT=1 --ISP=1 --MTS=1 --MTSIntraMaxCand=4 --MTSInterMaxCand=4 --LFNST=1 --JointCbCr=1
--LoopFilterDisable=1 --SAO=1 --TransformSkip=1 --TransformSkipFast=1 --TransformSkipLog2MaxSize=5 --SAOLcuBoundary=0 --ALF=1 --CCALF=1 --InternalBitDepth=10
--CostMode=lossless --InputChromaFormat=444 --ChromaFormatIDC=444 --QP=0 --BDPCM=2 --ColorTransform=1 --VideoFullRange=1 --ChromaTS=1 --DepQuant=0 --LMCSEnable=0 --RDOQ=0 --RDOQTS=0 --SBT=0 --ISP=0 --MTS=0 --LFNST=0 --JointCbCr=0 --VerCollocatedChroma=1
--LoopFilterDisable=1 --SAO=0 --TransformSkip=1 --TransformSkipFast=1 --TransformSkipLog2MaxSize=5 --SAOLcuBoundary=0 --Log2MaxTbSize=5 --ALF=0 --CCALF=0 --BIO=0 --PROF=0 --InternalBitDepth=0
--IntraPeriod=1 --GOPSize=1 --SearchRange=64 --QpInValCb="17 22 34 42" --QpOutValCb="17 23 35 39" --BCW=0 --BcwFast=0 --BIO=0 --CIIP=0 --Geo=0 --AffineAmvr=0 --LMCSUpdateCtrl=1 --LMCSOffset=0 --DMVR=0 --SMVD=0 --PROF=0 --ISPFast=1 --FastMIP=1 --FastLFNST=1 --FastLocalDualTreeMode=0 --AffineAmvrEncOpt=0 --MmvdDisNum=8
--OnePictureOnlyConstraintFlag=1 --IntraConstraintFlag=1 --Level=15.5 --Tier=high
--RateControl=0 --SEIDecodedPictureHash=1 --MaxLayers=1 --CbQpOffset=1 --CrQpOffset=1 --TemporalSubsampleRatio=1 --LCTUFast=1 --TemporalFilter=0 --DualITree=1
--MinQTLumaISlice=8 --MinQTChromaISliceInChromaSamples=4 --MinQTNonISlice=8 --MaxMTTHierarchyDepth=3 --MaxMTTHierarchyDepthISliceL=3 --MaxMTTHierarchyDepthISliceC=3 --MMVD=1
--Affine=1 --SubPuMvp=1 --MaxNumMergeCand=6 --LMChroma=1 --IMV=1 --MRL=1 --IBC=0 --AllowDisFracMMVD=1 --MIP=1 --PBIntraFast=1 --FastMrg=1 --AMaxBT=1 --HadamardME=1 --FEN=1 --FDM=1
The codec doesn't support the dimensions of the images indivisible by four

[benwaggoner]

Holy cow, you were not kidding.

Something in there caught my eye, though: A "Mixed Lossy Lossless" setting. This is my primary use case for HEIF/AVIF, which are more like a single-page PDF, if anyone would bother to support that; if this makes it into the final codec it'll mean desktop shared streams don't have to be absolute garbage in order to also show sections that can't be efficiently losslessly compressed.
Encoding mixed lossy/lossless in x265 is easy: just us the --cu-lossless flag. Every block will also get tested against the lossless mode. For some kinds of content, like bitmap art, lossless can be smaller than a high quality lossless encode.

Transform skip (--tskip) can provide similar improvement, but doesn't need to be lossless.

They are both pretty useless in typical film/video encoding, but can be very helpful with some kinds of synthetic noise-free content.

[foxyshadis]

Encoding mixed lossy/lossless in x265 is easy: just us the --cu-lossless flag. Every block will also get tested against the lossless mode. For some kinds of content, like bitmap art, lossless can be smaller than a high quality lossless encode.

Transform skip (--tskip) can provide similar improvement, but doesn't need to be lossless.

They are both pretty useless in typical film/video encoding, but can be very helpful with some kinds of synthetic noise-free content.

My bad. I dismissed --cu-lossless a while back because it didn't perform very well, and always preferred lossy over lossless even when lossless visual quality was far higher for a marginal bitrate gain. But that's an implementation detail, and wouldn't be any different here.

[benwaggoner]

My bad. I dismissed --cu-lossless a while back because it didn't perform very well, and always preferred lossy over lossless even when lossless visual quality was far higher for a marginal bitrate gain. But that's an implementation detail, and wouldn't be any different here.
VVC may have made it more effective as well. There are a lot of optional screen coding tools in HEVC that are built into VVC. "subjectively lossless" is quite different underneath for synthetic content versus continuous tone images. Rasterized text, for example, or pixel art.

[`Orum]

ffmpeg.exe -loglevel error -i "output1.png" -an -f rawvideo -frames 1 -vf scale=1564:1558:in_color_matrix=rgb:in_range=full:out_color_matrix=bt2020nc:out_range=full,format=yuv420p10le 113.yuv
EncoderApp_360.exe <snip>
The codec doesn't support the dimensions of the images indivisible by four
Wow, that works! Thanks :)

I wonder which of the options you set (that I didn't) were the key to getting it to work. I'm going to try and figure it out, removing one at a time until it doesn't work.

[Jamaika]

For those interested I put VVC photo converter on the example of the libbpg library. The files created are in vvc because libbpg only reads hevc files. I don't know the specifications for reading VVC files.
https://www.sendspace.com/file/abowus

[benwaggoner]

For those interested I put VVC photo converter on the example of the libbpg library. The files created are in vvc because libbpg only reads hevc files. I don't know the specifications for reading VVC files.
https://www.sendspace.com/file/abowus
Does anyone know of any work to implement VVC in HEIF as well?

[ksec]

Taken from a message of Gary Sullivan to the JVET reflector:

I am pleased to announce that ITU-T SG16 just declared official Consent on Recommendation ITU-T H.266 Versatile Video Coding (VVC). Consent on H.266 was declared at 1353 UTC (1553 local time in Geneva, 3 July 2020). VVC, which will also become ISO/IEC 23090-3 upon approval in the ISO/IEC approval process, is the latest in a series of very successful such jointly developed ITU-T Recommendations and International Standards for video coding, and is the direct successor to HEVC (Rec. ITU-T H.265 | ISO/IEC 23008-2) and AVC (Rec. ITU-T H.264 | ISO/IEC 14496-10). VVC provides significant coding efficiency improvements over HEVC. Plans are underway to conduct a verification test with formal subjective testing to confirm that VVC achieves about a 50% bit rate reduction vs. HEVC for equal subjective video quality. Test results have demonstrated that VVC provides about a 40% bit rate reduction for 4K/UHD test sequences using objective metrics. Application areas especially targeted for the use of VVC include ultra-high definition 4K and 8K video, video with a high dynamic range and wide colour gamut, and video for immersive media applications such as 360° omnidirectional video, as well as conventional standard-definition and high-definition video content. In addition to improving coding efficiency, VVC also provides highly flexible syntax supporting such use cases as subpicture bitstream extraction, bitstream merging, temporal sublayering, and layered coding scalability.

[hajj_3]

Taken from a message of Gary Sullivan to the JVET reflector:

Great news! Lets hope that hardware decoders don't take too long to come to market.

Now that it has been ratified the admins/mods should create a separate forum for it.

[ksec]

Great news! Lets hope that hardware decoders don't take too long to come to market.

Now that it has been ratified the admins/mods should create a separate forum for it.

Hardware is the easy part as I gathered all the design IPs will soon be ready.

Just waiting for MC-IF to announce terms, assuming they do agree on something, which is going to be the hardest part.

[FranceBB]

I am pleased to announce that ITU-T SG16 just declared official Consent on Recommendation ITU-T H.266 Versatile Video Coding (VVC). Consent on H.266 was declared at 1353 UTC (1553 local time in Geneva, 3 July 2020).

That's great news! :D


Just waiting for MC-IF to announce terms, assuming they do agree on something, which is going to be the hardest part.

Yeah... fingers crossed.


Now that it has been ratified the admins/mods should create a separate forum for it.

+1
A VVC H.266 section on Doom9 would be really cool.

[foxyshadis]

Great news! Lets hope that hardware decoders don't take too long to come to market.

Now that it has been ratified the admins/mods should create a separate forum for it.

Doesn't happen until there's wide interest in it. It took 3 years from people talking about AV1 to new forum, and 2+ years for H.264. HEVC might've been a special case, since everyone was salivating over it... and then just as quickly disappointed by it.

[birdie]

Taken from a message of Gary Sullivan to the JVET reflector:

Looks like encoding efficiency for near-lossless encoding for "standard" resolutions like 1080p, 720p and 480p won't increase much if at all which is super weird. H.265 did almost nothing for it, and H.264 remains the king. :(

[ksec]

This makes me wonder...... If MulticoreWare will be interested in x266.

[hajj_3]

This makes me wonder...... If MulticoreWare will be interested in x266.

Their best developer left a few years ago to work for a video encoding server company which is why x265 doesn't do so well compared to proprietary h265 encoders unlike x264 which beats proprietary encoders.

[Jamaika]

On the Astra 2E (28.2 ° E) satellite emission tests appeared in VVC compression, the future successor of the HEVC / H.265 standard. These experiments are conducted by the satellite operator SES and the French technology company ATEME specializing in solutions for the supply of video content.
At the moment, popular software is not ready to handle VVC streams. Therefore, it is not easy to preview the content. Satkurier.pl editors have managed to determine so much that the image itself is emitted at a rate of 20.55 Mbit / s - probably at a resolution of 8K. Although the audio track is reporting, it is not broadcast.
Technical parameters:
Astra 2E (28.2 ° E) tp. 14 (11.973 GHz, pol. V, SR: 31000, FEC: 9/10; DVB-S2 / 8PSK)

New codec 2020.06.04
https://www.sendspace.com/file/3l7d6z

[ksec]

Their best developer left a few years ago to work for a video encoding server company which is why x265 doesn't do so well compared to proprietary h265 encoders unlike x264 which beats proprietary encoders.

You mean Beamr? ( And BEAMR 5 is a god damn good encoder ).

In hindsight x264 was sort of the outliner, it sets the bar and expectation of a free encoder way too high. Dark Shikari was driving it with burning passion.

And MulticoareWare are now more focused in ML, Al, DataScience type of business. ( Cant blame them since that is where the money are right now )

[FranceBB]

Speaking of which, when do you think work on x266 will begin?

[LigH]

Not before the specs are "final"? ... Are they? :confused:
_

PS: Oh, I just learned it is. Newsletter (https://newsletter.fraunhofer.de/-viewonline2/17386/465/11/14SHcBTt/V44RELLZBp/1)

The licensing is promoted to be FRAND = "fair, reasonable and non-discriminatory" ... we will see.

[nevcairiel]

The licensing is promoted to be FRAND = "fair, reasonable and non-discriminatory" ... we will see.

Except thats not up to them, but the hundreds of patent holders, who will manage to ruin it again, I'm sure. Getting every patent holder into one pool that they can actually guarantee fair terms for is unlikely.

[ksec]

Except thats not up to them, but the hundreds of patent holders, who will manage to ruin it again, I'm sure. Getting every patent holder into one pool that they can actually guarantee fair terms for is unlikely.

In case anyone missed it, that is the purpose of MC-IF. If you look at the members page linked below [1], pretty much all patent holder are there. ( Represented by their respective group, such as Qualcomm by Velos Media)

So the single pool ( first part of the equation ) is done, getting out there terms is another matter though.

Personally I think a decent terms would be $1 per devices for hardware encoder and decoder with "NO CAP". And free software implementation for decoding. ( Preferably with Image Format exemption. VVC as an image is ridiculously good at low bpp )



[1] https://www.mc-if.org/our-members

[nevcairiel]

In case anyone missed it, that is the purpose of MC-IF. If you look at the members page linked below [1], pretty much all patent holder are there. ( Represented by their respective group, such as Qualcomm by Velos Media)


And that originally was also the plan of the MPEG-LA, and then HEVC Advance happened.

30 something companies seems pretty low to cover all the patents, which would have large overlap with HEVC and even H.264 still. MPEG-LA had over 40 companies in the HEVC patent pool, and thats not including those that jumped to HEVC Advance.

I hope they manage to make a fair and resonable situation happen, but knowing how many of those companies have behaved in the past, i'm not entirely confident.

[ksec]

And that originally was also the plan of the MPEG-LA, and then HEVC Advance happened.

30 something companies seems pretty low to cover all the patents, which would have large overlap with HEVC and even H.264 still. MPEG-LA had over 40 companies in the HEVC patent pool, and thats not including those that jumped to HEVC Advance.

I hope they manage to make a fair and resonable situation happen, but knowing how many of those companies have behaved in the past, i'm not entirely confident.

Well MPEG-LA started HEVC licensing with only ~20 companies. i.e They never reached an agreement and went ahead. That was how HEVC advance started.

And for the listed 3x Members in MC-IF, HEVC Advance is in there. As a matter of fact all of the current HEVC Pool are there. ( Velos, HEVC Advance, Fraunhofer) Along with Sisvel and United Patents, together there are well over a hundred companies represented and more.

AFAIK, there has never been a larger list of companies joining together for video codec.

Again, that is not to say they will agree on something. Or if the agreement will really be "reasonable" by other's definition.

Finger Crossed.

[NikosD]

An official press release of VVC/ H.266 from Fraunhofer HHI

50% less bit rate for same quality of H.265

https://newsletter.fraunhofer.de/-viewonline2/17386/465/11/14SHcBTt/V44RELLZBp/1

[hajj_3]

50% less bit rate for same quality of H.265

The Mpeg-LA said that HEVC had 50% better compression than h264 so i would take this claim with a pinch of salt. I'd be happy with 35% improvement.

VVC VTM 9.3 is out: https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/-/releases

Hopefully someone will do some extensive benchmarks using V9.3 comparing it to other codecs in terms of compression now that it has been ratified.

[benwaggoner]

The Mpeg-LA said that HEVC had 50% better compression than h264 so i would take this claim with a pinch of salt. I'd be happy with 35% improvement.
It was "up to 50%" and there are certainly cases where that is met. I would say the best HEVC encoders are about 2x better than the best H.264 encoders of 2012 with the HEVC spec was finished. H.264 encoders have gotten better in that time frame as well, although at a slower pace. In the same way, we can expect HEVC encoders to keep getting better well into the VVC era. Heck, Beamr has shown substantial H.264 encoder efficiency improvements in the last 18 months. We've even seen big MPEG-2 encoder improvements in the last five years. Moore's Law means we're always getting more MIPS/pixel and can figure out new ways to turn a lot more compute into incremental quality gains.

Hopefully someone will do some extensive benchmarks using V9.3 comparing it to other codecs in terms of compression now that it has been ratified.
Alas, we really can't compare codecs. We can compare encoders. That's a big reason why the 1st encoders of a new codec are far from 2x better than the mature encoders of the prior generation codec. It take a while before implementations catch up with older encoders, and even longer for encoder vendors to figure out how to optimally use all the new tools in the much more complex newer codec.

One advantage of VVC over, say, AV1, is that a VVC encoder can start with a HEVC encoder without that much tweaking, and then VVC-specific features can be added. That's how x265 started.

[Jamaika]

New codec 2020.07.07 v9.3
https://www.sendspace.com/file/i9uta6

[soresu]

One advantage of VVC over, say, AV1, is that a VVC encoder can start with a HEVC encoder without that much tweaking, and then VVC-specific features can be added. That's how x265 started.

It would have been an advantage if VVC was in the same position that HEVC was in over VP9.

In that case HEVC came out a year earlier than VP9, and VP8 had gained little traction beyond Youtube at that point.

This time AV1 has a 2 year lead, and several encoders both open and proprietary available with ASIC decoders trickling into the consumer marketplace.

Despite not being at quality parity with libaom, SVT AV1 can do much faster than real time HD on a single socket system - I would expect that to improve even further well before performant and feature complete software VVC encoders are in the mainstream.

[benwaggoner]

It would have been an advantage if VVC was in the same position that HEVC was in over VP9.

In that case HEVC came out a year earlier than VP9, and VP8 had gained little traction beyond Youtube at that point.

This time AV1 has a 2 year lead, and several encoders both open and proprietary available with ASIC decoders trickling into the consumer marketplace.
It's an advantage in that an equivalent maturity VVC encoder will be available sooner after standardization than has been true with AV1. Given that VVC is fundamentally better technoology, I imagine we'll see VVC encoders that beat the then-best available AV1 at quality @ perf @ bitrate by the end of 2021.

Despite not being at quality parity with libaom, SVT AV1 can do much faster than real time HD on a single socket system - I would expect that to improve even further well before performant and feature complete software VVC encoders are in the mainstream.
But the SVT AV1 still isn't competitive with commercial live HEVC encoders with quality @ perf @ bitrate. And in offline enocding, the best AV1 still isn't consistantly meeting let alone beating the best HEVC today.

[ksec]

We will see what happens.

I waited 5 years to prove my point TSMC will Fab 5nm SoC in 2020, I could wait another 3 for AV1.

[soresu]

It's an advantage in that an equivalent maturity VVC encoder will be available sooner after standardization than has been true with AV1. Given that VVC is fundamentally better technoology, I imagine we'll see VVC encoders that beat the then-best available AV1 at quality @ perf @ bitrate by the end of 2021.

I guess that depends on your definition of maturity.

The main HEVC encoder in use publicly is x265 - it's 8 years old now, and doesn't come close to the original MPEG promises for the codec, albeit HW265 does so clearly someone or several someones at MCW weren't giving it their A game.

That is with them using x264 as a base to speed up initial development.

Sure x265 can definitely do very well at low bitrates, but at high bitrates? Not so much. I've seen recent high bitrate HD encodes using both x264 and x265 at 10GB, and x265 definitely still has problems there.

Meanwhile at 8 years old x264 had already categorically beaten the incumbent best codec Xvid. (or is that just my memory playing tricks on me?)

Given that, either through laziness or lack of investment the x265 codec has actually shown slower development than x264.

Even if your prediction comes true, and I am fairly pessimistic about those chances given the history of HEVC implementations and the different nature of the ML based techniques - even then, if AOM choose to use SVT as a base for AV2 development, it could launch far faster and more performant than AV1/VP9/VP8 did, and make VVC's reign far shorter than that of HEVC.

From what I have seen in the experimental branch commits so far, AOM seem to be taking a similar ML guided/augmented take to VVC for AV2, and at least Google's talks at encoding summits certainly support that direction.

So I don't think VVC will remain in the lead for fundamentally better technology for very long, to say nothing of the less than likely outcome of a salient licensing platform for VVC in the near future - and that isn't even getting into the mess of uncertainty that the EVC pushers have made on top of all of this.

It seems almost like the proprietary codec pushers are actually trying to self destruct that path at this point, either through incompetence or greed, take your pick.

To me it makes more sense for those still pushing the proprietary angle to pre pool their patents to license at a fixed rate per year to AOM so that this post standardisation licensing musical chairs can be cut off at the knees - that way everybody that wants to get paid can still be paid.

I'm sure between the huge conjoined cash reserves of the main AOM members that they can work out an equitable fixed rate rather than waiting until the last year or 2 of a proprietary codec development to engage in a free for all.

[soresu]

And in offline enocding, the best AV1 still isn't consistantly meeting let alone beating the best HEVC today.

Do you mean to say that Visionular's results for Aurora AV1 are false?

Because they purported to be exceeding libaom quality at faster speeds than x265 all the way back at the Big Apple event last year.

If they weren't lying, I would assume that they would probably have improved it further still by now.

[benwaggoner]

Do you mean to say that Visionular's results for Aurora AV1 are false?

Because they purported to be exceeding libaom quality at faster speeds than x265 all the way back at the Big Apple event last year.

If they weren't lying, I would assume that they would probably have improved it further still by now.
I very much doubt they are lying. But in my experience 85% of comparisons like that have failed due to some mismatch or another. It is very common for an encoder company to choose a metric and a set of test content they focus on, and then report results on that which aren't borne out using a broader set of content and scenarios.

I'm not suggesting there is anything specific to that vendor along those lines. But I personally haven't seen real-world longer-form content where AV1 is reliably superior to HEVC. AV1 encoders just don't (yet) have the breadth of psychovisual optimization across the huge range of sources and scenarios of the best HEVC encoders.

One likely exception to that is very grainy/noisy content, as AV1 can remove grain on encoding and resynthesize it on on the decoder side. I've not seen a mature degrain-and-paramterize solution integrated into an AV1 encoder. But I anticipate a good one could beat HEVC for grainy content at moderate-low bitrates. Grain just takes so many bits, and HEVC simply doesn't have an equivalent tool.

H.264 for HD-DVD also had a film grain sythesis feature. But the MIPS/pixel available 14 years ago were tiny compared to now - just degraining and parametrizing was a R&D thing, not production ready. And the synthesis model was a lot more primative, so the results couldn't be as fine tuned.

[LigH]

New upload: VTM Encoder Version 9.3 [Windows][GCC 10.1.0][64 bit] (https://www.mediafire.com/file/ywlpxvskbd06ccs/VVCSoftware_VTM-9.3_6611add1.7z/file) 6611add1

[nakTT]

You mean Beamr? ( And BEAMR 5 is a god damn good encoder ).

In hindsight x264 was sort of the outliner, it sets the bar and expectation of a free encoder way too high. Dark Shikari was driving it with burning passion.

And MulticoareWare are now more focused in ML, Al, DataScience type of business. ( Cant blame them since that is where the money are right now )
Speaking of Dark Shikari, yeah i remember those days when he was the main developer for x264, burning passion. What happen to him nowadays? Haven't heard any news of him involve in any of video compression coding project anywhere.

No wonder x265 isn't as competitive against the commercial version of H.265 as x264 back in the days.

Hope this H.266/x266 would be a competitive one.

[benwaggoner]

Last I heard of Dark Shikari she was doing custom contract work on x26x. But I've not heard anything from/about her for, sheesh, maybe five years now?

x264 was a miraculous beast. Key to its success was a global audience of video pirates competing on who could release the smallest best quality clip the fastest, across very diverse real world content, without any religion on specific objective metrics. One of the reason why today's competitive encoders are better today is that they've adopted a lot of what x264 innovated on and adopted a lot of the strengths of its development process.

VVC is 1-2 orders of magnitude more complex than H.264 was, so I'm not sure how practical having development lead by unpaid enthusiasts is. A large coordinated team is probably required to squeeze out results. Open source is certainly viable.

[Blue_MiSfit]

No wonder x265 isn't as competitive against the commercial version of H.265 as x264 back in the days.

Hope this H.266/x266 would be a competitive one.


Don't confuse the standard with an encoder implementation :)

There is no "commercial version" of H.265. There's just the standard, and then a lot of encoders that implement it - one of which is x265, which happens to be free. MultiCore Ware also sells commercial licenses. They also sell a version of x264 and x265 with a handy abstraction layer for certain use cases called UHDKit.

Commercial HEVC / H.265 encoder options include:

Ateme, AWS Elemental, MediaKind, Harmonic, Ittiam, Tenecent, Dolby, etc...

[ksec]

Over At Reddit [1] , someone made available their VVC encode along with comparison to other codec. I have included the download link [2], and some of the most important graphs within the zip to save everyone the download.

https://i.imgur.com/iAXiyFG.png

https://i.imgur.com/sl7xANO.png

https://i.imgur.com/vwaqpFC.png



[1] https://www.reddit.com/r/VVC/comments/hpc0r6/any_vvc_stream/fy1860f?utm_source=share&utm_medium=web2x

[2] https://drive.google.com/file/d/1d3z8TDqailCBCwzNwnoyTF81CC-Kmo_y/view?usp=sharing

[hajj_3]

Do we know whether the VVC reference decoder will be integrated in to FFmpeg any time soon? It would be nice to let the masses to benchmark it.

[FranceBB]

@ksec... very interesting results. H.266 did way better than x264 and x265 at both low and high bitrates. It was also better than VP9 as we expected, but it couldn't quite get a grip on AV1 at high bitrates. I wonder whether it's because AV1 encoders have been available for quite some time now and are more mature than the H.266 reference encoder or if it's due to the codec standard/implementation itself...
I guess some other tests will have to be done to evaluate this, but judging from the first data, we're definitely heading in the right direction. Let's wait an see.

Do we know whether the VVC reference decoder will be integrated in to FFmpeg any time soon? It would be nice to let the masses to benchmark it.
Have reference encoders ever been integrated into ffmpeg? I mean, I might be wrong, but I don't really remember any of them...
I guess we're gonna have to wait for x266 work to begin before we'll see anything in ffmpeg...

[ksec]

but it couldn't quite get a grip on AV1 at high bitrates.


Is that in other slides? Based on the three slides I posted What I am seeing is AV1 using higher bitrate to achieve slightly better results. In terms of similar bitrate overall VVC is still ~10 to 20% better.

I wonder whether it's because AV1 encoders have been available for quite some time now and are more mature than the H.266 reference encoder or if it's due to the codec standard/implementation itself...
I guess some other tests will have to be done to evaluate this, but judging from the first data, we're definitely heading in the right direction. Let's wait an see.

Yes AV1 2.0 ( or to be more precise; Libaom2.0 ) has anywhere between 5 - 10% quality improvement from its 1.0 release. But bear in mind all MPEG / JVET reference encoder are never tuned for quality. Which is different to non-MPEG ones. And if we look back at HM ( HEVC Reference Encoder ) or JM ( AVC Reference Encoder ) and compare to x264 or x265, there are quite a measurable differences.

Also just note the final spec is draft 10, and current VTM is not at that level yet. In theory there should be a VTM 10 coming. ( Unless there isn't any change between VTM 9.3 and VTM 10 which I do not have any idea ). And Levels, Features and Profiling is still in the work before the whole Spec is finished.

But yes judging from the outside, it is definitely heading in the right direction.

[MoSal]

But bear in mind all MPEG / JVET reference encoder are never tuned for quality.


What?
"Objective" quality is exactly what they are tuned for. That's how it guides development. What it's not tuned for at all is speed.


And if we look back at HM ( HEVC Reference Encoder ) or JM ( AVC Reference Encoder ) and compare to x264 or x265, there are quite a measurable differences.


In a stream features (B-frames, GOP size, ...etc) apples-to-apples comparison, which one scores better in objective metrics (sans VMAF since it wasn't around when HM was developing), HM or x265?

[ksec]

What?
"Objective" quality is exactly what they are tuned for. That's how it guides development. What it's not tuned for at all is speed.

Yes especially VMAF As you mentioned below. I guess it would be more accurate to say Reference Encoder are "tested" against those Objective Metrics, and not "tuned" for it. I am not sure if this get the point across.


In a stream features (B-frames, GOP size, ...etc) apples-to-apples comparison, which one scores better in objective metrics (sans VMAF since it wasn't around when HM was developing), HM or x265?

Depends, it is definitely lower in PSNR if I remember correctly. The x264 lineage has something against PSNR even in tuned settings. And depending on tested clips. But then I would not be surprised if there are commercial encoder that could yield a 10+% better PSNR / SSIM curve. As they are often the marketing number commercial encoder likes to use, although things may have changed with the introduction of VMAF. ( You can always do something better once they are the only matrix you are measuring against ) By no means VMAF is perfect, it is just tech industry as a whole has always like something new to market.

[nevcairiel]

Do we know whether the VVC reference decoder will be integrated in to FFmpeg any time soon? It would be nice to let the masses to benchmark it.

MPEG reference software is typically not usable in the real-world. Its designed to serve as an example, not as something you actually use. They are generally slow and awful to use.

So no, thats likely never going to happen. If enough developers are actually interested in VVC, an actual native ffmpeg decoder has to be developed and optimized. And if developers can be motivated to do that depends on many things. The easiest motivation would actually be companies that have a use for such a decoder to actually fund development.

[benwaggoner]

In a stream features (B-frames, GOP size, ...etc) apples-to-apples comparison, which one scores better in objective metrics (sans VMAF since it wasn't around when HM was developing), HM or x265?
It's expensive to test with true MOS double-blind subjective measurements. But for real-world scenarios (rate control with VBV, particular GOP cadence, edits & transitions, and longer form content instead of test clips) I would expect a well-tuned x265 to beat HM. Certainly when comparing at fixed encoding times!

I expect x265 will beat the VVC test encoder for most real-world scenarios, encoding time aside, due to all the psychovisual optimizations.

[MoSal]

It's expensive to test with true MOS double-blind subjective measurements. But for real-world scenarios (rate control with VBV, particular GOP cadence, edits & transitions, and longer form content instead of test clips) I would expect a well-tuned x265 to beat HM. Certainly when comparing at fixed encoding times!

I expect x265 will beat the VVC test encoder for most real-world scenarios, encoding time aside, due to all the psychovisual optimizations.

This answers the exact opposite of what I (rhetorically) asked.

[LigH]

It's mostly due to "HM" being a "reference encoder", remember: Its purpose is to produce a correct bitstream according to specifications, not a most efficient encoding with a visually pleasant result.

[MoSal]

Maybe I didn't express my point clear enough.

The context is the objective results of VVC vs. other codecs that was shared.

Then @ksec writes:

But bear in mind all MPEG / JVET reference encoder are never tuned for quality. Which is different to non-MPEG ones. And if we look back at HM ( HEVC Reference Encoder ) or JM ( AVC Reference Encoder ) and compare to x264 or x265, there are quite a measurable differences.


The context is not about subjective quality or encoding speed. It's about max objective scores. And MPEG/JVET encoders are the ultimate placebo mode that targets those. To say that they are not tuned for "objective" quality is incorrect.

My rhetorical question about HM vs. x265 was specifically asked because we actually have the numbers:
https://forum.doom9.org/showthread.php?t=174540

[LigH]

Well, of course you may compare encoders with "objective" quality metrics if you like. But what would the results tell the consumer? Several "objective metrics" (especially PSNR, and partially even SSIM) are known to have academic cases where they return values suggesting a minimal loss of quality, but human viewers would rate these results quite annoying. So this whole topic appears to be rather academic and less relevant to the average audience. At least in my bold opinion. And I guess I am not alone here.

To try one specific approach to the feature-dependent attributes of quality loss: The x265 encoder has this SAO feature which is also named "smooth all out" for its side effect. If you have plenty of bitrate, a.k.a. a fine quantization, it is recommended to disable it. This is one of the more "brute" features of HEVC to reduce details to spare bitrate where it may be tolerable, but it requires better tuning. I guess VVC will have a few more of such "smart loss" features, and we will have to learn how smart they are. But they are probably in the wide field of psychovisual algorithms. Subjective filters, to be disabled for your idea of an "objective" comparison. You may only accept the basic improvements, like larger coding units and more variable fractions of them.

[nakTT]

Last I heard of Dark Shikari she was doing custom contract work on x26x. But I've not heard anything from/about her for, sheesh, maybe five years now?

x264 was a miraculous beast. Key to its success was a global audience of video pirates competing on who could release the smallest best quality clip the fastest, across very diverse real world content, without any religion on specific objective metrics. One of the reason why today's competitive encoders are better today is that they've adopted a lot of what x264 innovated on and adopted a lot of the strengths of its development process.

VVC is 1-2 orders of magnitude more complex than H.264 was, so I'm not sure how practical having development lead by unpaid enthusiasts is. A large coordinated team is probably required to squeeze out results. Open source is certainly viable.
Thanks for the reply. I actually aware of the she part. It's just that the last time i heard of him working on anything was when DS was still a he thus the reason for using he instead of she. Anyway, i wish her well.

Other than this new VVC, I also hope the developer can squeeze some more juice out of the current x265. Do you think there are still much potential in x265, especially with regard to efficiency improvement?

[ksec]

Thanks for the reply. I actually aware of the she part. It's just that the last time i heard of him working on anything was when DS was still a he thus the reason for using he instead of she. Anyway, i wish her well.

Other than this new VVC, I also hope the developer can squeeze some more juice out of the current x265. Do you think there are still much potential in x265, especially with regard to efficiency improvement?

I thought the "She" used here was reference to the identity online being a female Anime character.

His real name is Jason Garrett-Glaser.

[Blue_MiSfit]

Actually, her name is Fiona now.

https://en.wikipedia.org/wiki/X264

[FranceBB]

I was actually aware of the she part.


What?



It's just that the last time i heard of him working on anything was when DS was still a he thus the reason for using he instead of she.


What?! x2 O_O


Actually, her name is Fiona now.

Please, tell me this is a joke...
Not Jason... Not him...
It would be the fall of a hero for me... :(

[NikosD]

Please, tell me this is a joke...

Not Jason... Not him...

It would be the fall of a hero for me... :( Why all this drama ?
Not everybody in this world is sure about his/her sex and sexuality.
The Wachowskis are the most famous people who have done the same thing.
It could be a characteristic of a genius.

[stax76]

Please, tell me this is a joke...
Not Jason... Not him...
It would be the fall of a hero for me... :(

Weird comment, I think rule 15 applies here.

[FranceBB]

It could be a characteristic of a genius.

Dark Shikari was a genius indeed, whether that particular thing is the characteristic of geniuses, I don't know...
Perhaps... I just hope he/she is happy with his/her choice...

I think rule 15 applies here.

Yeah, sorry for derailing the topic, I didn't mean to.
Now, back on topic and back to VVC:

Based on the three slides I posted What I am seeing is AV1 using higher bitrate to achieve slightly better results. In terms of similar bitrate overall VVC is still ~10 to 20% better.

It is, the higher score is limited to the high bitrates, however they're not so unthinkable if you consider real world scenarios, which leads me to the question: why? Was it because of some fine details that were averaged/blurred out in VVC and were not in AV1? Was it because of grain retention? I mean, a screenshot of scores doesn't tell us much...
Anyway, the last time I encoded a test sample with the reference encoder was in December 2018, perhaps it's time for me to encode something again and compare it with other codecs this time. I'll try to put something together next week... maybe... unless I'm too overwhelmed with other things that my colleagues keep assigning me...

[Blue_MiSfit]

Thank you for quickly getting back on topic. My takeaway is that no ill will was intended, and that we all have the utmost respect for D_S and wish her the best :)

Let's all please be respectful to each other. Thank you.

[ksec]

Thank you for quickly getting back on topic. My takeaway is that no ill will was intended, and that we all have the utmost respect for D_S and wish her the best :)

Let's all please be respectful to each other. Thank you.

Thanks for the correction, my apology if I have offended anyone. Utmost Respect to DS and from the bottom of my heart I wish her all the best.



It is, the higher score is limited to the high bitrates,

Well I wouldn't call 1.5Mbps high bitrate. :D Let wait until VVC settle down and get a production encoder to play around before we make a judgement. Reference Encoder are really only good for compliance.

I am also noticing quite a bit of activity over at MC-IF. So lets hope we have more news soon.

Edit: Pool Administrator Selected by 2020 or Early 2021 before they talk about licensing terms. :/

[Mosu]

I read that the VVC/h.266 standard was finalized in July. Great. But is it actually available for purchase yet? I wasn't able to find it, neither on the ISO website, nor on the IEC or ITU-T websites. But I find each of those somewhat confusing to navigate; it's perfectly possible that I simply missed them.

If the standard's not available for purchase yet, any idea when it will be (roughly)?

[foxyshadis]

I read that the VVC/h.266 standard was finalized in July. Great. But is it actually available for purchase yet? I wasn't able to find it, neither on the ISO website, nor on the IEC or ITU-T websites. But I find each of those somewhat confusing to navigate; it's perfectly possible that I simply missed them.

If the standard's not available for purchase yet, any idea when it will be (roughly)?

You can buy the draft at ISO/IEC DIS 23090-3 (https://www.iso.org/standard/73022.html). It's not yet granted full ISO approval status, so it's not shown in browsing. Note that buying the draft doesn't entitle you to the final standard, which is incredibly annoying.

Edit: For more fun, the JVET site (https://jvet.hhi.fraunhofer.de/) has been taken down, too.

[Mosu]

Thanks. I think I'll wait for the final, then.

[olduser217]

The latest draft (not final) can be found at http://phenix.it-sudparis.eu/jvet/
Choose the June 2020 meeting, document S2001.

[amayra]

i refuse to touch anything not Royalty-free when it come to codec

[birdie]

i refuse to touch anything not Royalty-free when it come to codec

It's not clear why you feel entitled to share your opinion in this topic. If you refuse to touch anything not totally opensource/free, then what are you doing in this topic?

[benwaggoner]

@ksec... very interesting results. H.266 did way better than x264 and x265 at both low and high bitrates. It was also better than VP9 as we expected, but it couldn't quite get a grip on AV1 at high bitrates. I wonder whether it's because AV1 encoders have been available for quite some time now and are more mature than the H.266 reference encoder or if it's due to the codec standard/implementation itself...
I guess some other tests will have to be done to evaluate this, but judging from the first data, we're definitely heading in the right direction. Let's wait an see.
It's really hard to say without seeing the specifics of the test parameters. As a reference encoder, the VVC VTM won't have much psychovisual tuning while libaom has gotten quite a lot. Also libaom has gotten a lot of VMAF tuning, so we should expect its VMAF scores to somewhat outperform its actual subjective quality. Also, VMAF isn't a sensitive instrument comparing at high quality and bitrates. Only MOS testing has been usefully informative at looking at efficiency of near-transparent quality.

Speed doesn't mean much either, as libaom has gotten lots of performance tuning. The libvpx/libaom codecs are sort of weird combinations of reference encoders and production encoders.

Have reference encoders ever been integrated into ffmpeg? I mean, I might be wrong, but I don't really remember any of them...
I guess we're gonna have to wait for x266 work to begin before we'll see anything in ffmpeg...
Yeah, reference decoders are typically too slow for practical use, and carry a ton of complexity as they support ALL the features of the bitstream, not those in targeting Profiles and Levels. Practical decoders start by focusing on a practical subset of features, optimizing those, and then adding optimization of more features once the basics get done. For example, AV1 decoders got fast at 8-bit decode before they spent much time on 10-bit.

[benwaggoner]

Thanks for the reply. I actually aware of the she part. It's just that the last time i heard of him working on anything was when DS was still a he thus the reason for using he instead of she. Anyway, i wish her well.
She was definitely active in consulting and licensing during and after her transition. She remained quite active in development well after her participation in public discussions had tapered off.

As a side point, best practice is to refer to someone as having been their current gender retroactively, as someone's internal identity is very often established well before their public identity conforms to that.

Other than this new VVC, I also hope the developer can squeeze some more juice out of the current x265. Do you think there are still much potential in x265, especially with regard to efficiency improvement?
Compression efficiency? Sure, there's plenty of room to keep optimizing. Even MPEG-2 has seen material improvements over the last few years, and HEVC has SO many.

Beamr has demonstrated some very promising improvements over x265. I bet the ABR required for a given MOS in HEVC can drop another 40-50% over the next decade, given how many tools there are an how much flexibility there is to apply them. Moore's Law gives us more MIPs/pixel every year. The whole field of applying AI/ML to improving encoding is still new, and promises some really big improvements. There are whole approaches to interframe tuning that are only just being poked at today.

I'd expect we're ~2 years out from the best VVC production encoders being materially better than the best HEVC encoders in quality @ bitrate @ perf.

[hajj_3]

VTM v10.0 is out, large changelog: https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/-/releases/VTM-10.0

[amayra]

It's not clear why you feel entitled to share your opinion in this topic. If you refuse to touch anything not totally opensource/free, then what are you doing in this topic?

why you feel entitled to comment about my opinion in this topic ?

[Audionut]

Well, generally the discussion should be relevant and move the topic forward.

Irrelevant personal opinions, while valid, add nothing of value to the community. And that is what doom9 is, a community, not your personal opinion space.

[LigH]

New upload: VTM Encoder Version 10.0 [Windows][GCC 10.2.0][64 bit] (http://www.mediafire.com/file/f31a8ee4107g8c3/VVCSoftware_VTM-10.0_16bc143c.7z/file) 16bc143c

[soresu]

For me the big surprise is the AV1 MPEG-4.

I have to agree with this - it's very odd that all Yotube AV1 videos are encapsulated in MP4 rather than webm/mkv.

[Blue_MiSfit]

I'm sure YouTube is doing this for a good reason. I wouldn't be surprised if this is because the tooling surrounding fragmented MP4 is vastly more widespread than the tooling surrounding MKV, especially on the client side. While it's possible to deliver content using MPEG DASH and WebM segments, this isn't something most players support, so almost nobody does it. I'm only aware of YouTube ever having done this.

fMP4 is widely used in both DASH and HLS now, and is getting more and more widespread device support. Also factor in that when encrypting content it's desirable to have fMP4 with AES-CBCS encryption so you can take advantage of Widevine, PlayReady, and FairPlay all from a single set of files (delivered via DASH or HLS as clients prefer).

All of that is possible with fMP4, in a way that's broadly compatible. I don't think the same can be said for WebM.

MP4 is a good container format, and it's the way forward for all scalable video delivery to customers (except for ultra low latency cases where RTP / WebRTC are still better suited). We have all the new contribution protocols like SRT and RIST, and all the new "SDI replacement" protocols like NDI to handle the professional content production cases for live too :)

[benwaggoner]

I have to agree with this - it's very odd that all Yotube AV1 videos are encapsulated in MP4 rather than webm/mkv.
Why WOULD it be in MKV? It's not like MKV is better engineered or something, or handles scenarios that MPEG-4 can't.

I think the practical difference is the .mkv extension only gets opened by players who can handle the rich elements, so a too-simple player doesn't even try. Which is a valid reason to use it when trying to package up a whole media experience into a single file for download.

In the adaptive streaming world, things like subtitles and alternate languages are handled with URLs to specific files in the manifest, so only the needed assets for a given session need to get downloaded.

[Jamaika]

I don't know how it is in the US, but in the EU popularization and lack improvement MP4 codec is justified by company patents and legal acts RODO or ACTA2. New codec AV1 in mp4 - ok, but codec description is limited and archaic. Is the description recommended for processed video? Not recommended.
Card payments were reluctantly introduced in logistics in the era of KV. And it turned out that nobody don't want to pay in the KV era. GPS in the movie, money and crazy vacations. It's tax proof on the tray. What youtube or facebook?
The MKV container is considered by many companies as a pirate that has ruined DVD / Bluray. Great that it has extra subtitles, other functions. Unfortunately, it is for amateur programs.
What will the MP5 be like? I have no illusions as a layman. The MP5 will be an even more encrypted container for fast tracking by security systems.
Will MKV contain MPEG5 container under VVC ??? How should I know, but it probably won't be free.

[birdie]

News: x266 is already in development (https://multicorewareinc.com/x266-a-state-of-the-art-open-source-code-for-vvc-encoding-by-multicoreware-inc/):

MulticoreWare announces the formation of x266 consortium and development of an open source code for VVC encoding is already underway. Similarly, MulticoreWare’s x265 consortium led the development of the open source code x265 for HEVC based encoding and become the mmost widely used HEVC encoding software.

Application areas of x266 will include encoding High Definition(HD) and Ultra High Definition(UHD- 4K and 8K) video for broadcasting, live streaming, Over The Top(OTT) video distribution, Adaptive Bit Rate(ABR) streaming, video storage and archiving, surveillance, screen content sharing, video teleconferencing, video games, eSports, immersive media such as 360-degree video, Virtual Reality (VR) etc.

x266 will be able to encode video with Standard, High Dynamic Range and Wide Color Gamut. It will also offer a user flexibility to trade-off speed of encoding with coding efficiency. Initial version of the x266 software will support single layer coding of 10 bits video with 4:2:0 chroma format. More advanced versions will support multilayer coding, higher than 10 bits depth video and higher than 4:2:0 chroma formats.

[Greenhorn]

non-reference (?) VVC implementation by Fraunhofer HHI:

https://github.com/fraunhoferhhi/vvenc

Seems to be in a very early state.

Offers a simple encoder with 4 presets and one tuning option, and multithreading, but no screen-content features, together with a complex encoder which seems to be a re-implementation of the VTM.

[Jamaika]

non-reference (?) VVC implementation by Fraunhofer HHI:

https://github.com/fraunhoferhhi/vvenc

Seems to be in a very early state.

Offers a simple encoder with 4 presets and one tuning option, and multithreading, but no screen-content features, together with a complex encoder which seems to be a re-implementation of the VTM.
Thanks for the info. Does this library have any JVETVVC history? Threads added.

Edit:
Added encoder VVEncoderApp.exe:
VVEncoderApp.exe --preset medium -i 111.yuv -s 1280x720 -t 4 -b 3000 -o str.266
Strange. Encoder isn't compatibile with Elecard StreamEye 4.5.974.
Time consuming coding problem. The encoder and decoder have to be created separately.
I don't know can user create any GOP?
https://www.sendspace.com/file/tjn6vy

[hajj_3]

There is a test transmission on a european satellite for a VVC broadcast: https://www.digitalbitrate.com/dtv.php?mux=11973&pid=7249&live=69&sec=0&lang=en

[Jamaika]

I've been using GPAC MPEG4 very little lately. I noticed that 'initial tests for VVC support' has been added under OPENVVC.
I wonder. Will VVC be possible to import into MPEG4 container or become MPEG5 container?
https://github.com/gpac/gpac/commit/a85373de5769e347f1f572938b87924b47e2ba3e

[FranceBB]

There is a test transmission on a european satellite for a VVC broadcast: https://www.digitalbitrate.com/dtv.php?mux=11973&pid=7249&live=69&sec=0&lang=en

Yep.
Astra 2E (28.2 ° E) tp. 14 (11.973 GHz, pol. V, SR: 31000, FEC: 9/10; DVB-S2 / 8PSK)

It was an 8K H.266 VVC 20.55 Mbit/s before.
Together with the audio channels it seems to be 27 Mbit/s now, though.

Doesn't look bad: 8K VVC Screenshot (https://i.imgur.com/ziXGue4.jpg)

I mean, sure, if you take a look at low lights like in this part, there's a lot of noise in both luma and chroma:

https://i.imgur.com/jPziOu3.png

And in other parts, everything looks blurry and averaged out, but still, we're talking about 20-27 Mbit/s for an 8K stream, so it's not really bad.

https://i.imgur.com/BQMgJrD.png

As a matter of fact, broadcasting 8K contents at around 25 Mbit/s in H.266 VVC just like we're doing for 4K contents in H.265 HEVC at the very same bitrate would be a huge achievement.
Besides, I would totally prefer a blurry approach compared to a blocky one; after all, blocking is immediately noticeable by human eyes, while blurring is kinda not.
It looks like H.266 VVC continued with the same approach H.265 HEVC had and improved from there:

https://i.imgur.com/FtUC669.png

(Remember that those last screenshots are parts of an 8K frame)

[LigH]

Right, other codecs might have to flatten out noise a lot more to achieve this bppf ratio. May look even less obvious in motion.

[benwaggoner]

Right, other codecs might have to flatten out noise a lot more to achieve this bppf ratio. May look even less obvious in motion.
And the psychovisual value of a pixel at 8K is very, very different than at 1080p. Different kinds of visual distortion will have different impacts at such different pixel density. For example, dithering-like artifacts are going to be essentially invisible at 8K, since small-moderate differences between individual pixels are effectively invisible.

[xooyoozoo]

non-reference (?) VVC implementation by Fraunhofer HHI:

https://github.com/fraunhoferhhi/vvenc

Seems to be in a very early state.

Offers a simple encoder with 4 presets and one tuning option, and multithreading, but no screen-content features, together with a complex encoder which seems to be a re-implementation of the VTM.

They have a whitepaper (https://www.hhi.fraunhofer.de/fileadmin/Departments/VCA/MC/VVC/VVEnc-v0.1-v1.pdf) with a few more details.

The most relevant performance graph:
https://i.imgur.com/W7BS2ZC.png

The higher quality modes are still a magnitude too slow, but it's nice to see a (more) performant encoder that matches reference quality.

If they add scene-change detection and rate-control, the project becomes an almost-useable enthusiast encoder. :)

[benwaggoner]

The higher quality modes are still a magnitude too slow, but it's nice to see a (more) performant encoder that matches reference quality.

If they add scene-change detection and rate-control, the project becomes an almost-useable enthusiast encoder. :)
Wow, that would be an incredible accomplishment this early in a codec's history.

A huge but rarely discussed advantage of the MPEG line of codecs is that each generation is heavily based on the previous one. So it's relatively straightforward to take an existing encoder and add some of the tools of the next one to get a compliant bitstream of reasonable quality. Not easy in absolute terms by any means, but relatively easy compared to building an encoder for a new codec without high-quality encoders to start with.

Back in the streaming wars, this was also a big reason why RealVideo and Windows Media codecs were able to come out with improvements so rapidly. Newer versions used the prior encoder as the basis, with new tools added. Being closed source and software only made compatibility a lot easier too, of course.

H.264 was the first time an open standards based approach demonstrated a huge advantage over proprietary codecs, a testament to the effectiveness of having many experts and stakeholders collaborating together.

[hajj_3]

VTM 10.2 is out: https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/-/releases

[LigH]

New upload: VTM Encoder Version 10.2 [Windows][GCC 10.2.0][64 bit] (https://www.mediafire.com/file/wy07e2whnhoa577/VVCSoftware_VTM-10.2_ec4bb116.7z/file) ec4bb116

[Rusyn]

Hi, I am working on the latest version of VTM for VVC (10.2). I would like to know how many percent of a given frame is encoded using the affine transform. I assume that to figure it out, I need to know the total number of encoded macroblocks, and then how many of them were encoded using the affine transform, but I have no idea what lines of code in which encoder / decoder .cpp files I should add / modify. I would be grateful for any suggestions / tips. Thank you in advance

[FranceBB]

ffmpeg.exe -i "AVS Script.avs" -strict -1 -an -f yuv4mpegpipe -vf scale=848:480:in_color_matrix=bt709:in_range=limited:out_color_matrix=bt709:out_range=limited,format=yuv420p 111.yuv
| encoder.exe -i 111.yuv -b "raw_video.vvc" -wdt 848 -hgt 480 --Profile=auto --Level=5.1 --Tier=main --FramesToBeEncoded=150
--FrameRate=30000/1001 --InputBitDepth=8 --OutputBitDepth=8 --InternalBitDepth=8
--InputChromaFormat=420 --ProgressiveSource
--IntraPeriod=-1 --GOPSize=4 --TargetBitrate=25000
--CTUSize=32 --MaxBTLumaISlice=32 --MaxBTChromaISlice=32 --MaxBTNonISlice=32
--MaxTTLumaISlice=32 --MaxTTChromaISlice=32
--MaxTTNonISlice=32 --Log2MaxTbSize=5
--ConformanceWindowMode=0 --SEIDecodedPictureHash=3
--BitstreamFile=vvc.bitsteam

pause





Output:

Error: found fewer Reference Picture Sets than GOPSize
Error: Invalid GOP structure given

How can I set the reference picture sets? --ref doesn't clearly work and I can't find anything in the documentation

[LigH]

As this seems to be a question specific to x266, it might better be asked in the x266 VVC Encoder (https://forum.doom9.org/showthread.php?p=1922993) thread. This one is rather generic or related to the Fraunhofer HHI reference.

I just even learned that x266 is already available...

Or not? Do you refer to the work of chenm001 who is not related to Multicoreware? Ooh, horay for trademarks.

[FranceBB]

Ah, no, no, sorry (I made a mistake and pasted something I shouldn't have pasted), now I'm referring to the VTM reference encoder by Fraunhofer, the one Jamaika has been posting about all the time.
But yeah, there are a lot of weird naming conventions out there right now, it's a bit of a mess.
And... no, x266 by Multicoreware isn't publicly available yet.
Still, my issue is that I get

Error: found fewer Reference Picture Sets than GOPSize
Error: Invalid GOP structure given

however I specified the correct GOP with a size of 4 and I set the --IntraPeriod to -1 which means automatic, so it should be ok.
I also took care of the CTU size and made sure that all the Slices were the same (so at least equal or less than it) and I set --Log2MaxTbSize to be less than 6, as suggested.
Still, it's complaining again. Why?
Besides, I think it should really allow default settings to go through rather than throwing errors all the time.
I mean, if someone doesn't specify anything, it throws an error 'cause it wants things to be specified.
If someone specifies them wrong, it doesn't clearly work, however there's very little documentation (at least, that's what I've found).
It's a bit of a pain to work with it, honestly...

[mikahawkins1]

It is pretty good when it comes to decoding.

[quietvoid]

I'm not sure a GOP with size 4 is gonna work, at least vvenc only allows 16 and 32.
The VTM example config files as well.

[FranceBB]

I'm not sure a GOP with size 4 is gonna work, at least vvenc only allows 16 and 32.
The VTM example config files as well.

I set it to 16 and 32. Same thing happens. I mean, I get the very same error message.

[quietvoid]

Okay, so it's back to having to specify the whole GOP structure. I can reproduce the same error when removing all the Frame lines.
In config files, it refers to this: https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/-/blob/master/cfg/encoder_randomaccess_vtm.cfg#L20-51

I don't know if they can be specified by command line :)

[Jamaika]

Output:

Error: found fewer Reference Picture Sets than GOPSize
Error: Invalid GOP structure given
You aren't using correct codec. This one is experimental and for setting only GOP = 16 or 32 in config.
You should use the vvenc and vvdec with multithread versions.
however I specified the correct GOP with a size of 4 and I set the --IntraPeriod to -1 which means automatic, so it should be ok.
I also took care of the CTU size and made sure that all the Slices were the same (so at least equal or less than it) and I set --Log2MaxTbSize to be less than 6, as suggested.
Still, it's complaining again. Why?
Besides, I think it should really allow default settings to go through rather than throwing errors all the time.
I mean, if someone doesn't specify anything, it throws an error 'cause it wants things to be specified.
If someone specifies them wrong, it doesn't clearly work, however there's very little documentation (at least, that's what I've found).
It's a bit of a pain to work with it, honestly....
These were the settings for screenshot at GOP = 1. Then you can skip config.

[FranceBB]

You aren't using correct codec. This one is experimental and for setting only GOP = 16 or 32 in config.
You should use the vvenc and vvdec with multithread versions.

These were the settings for screenshot at GOP = 1. Then you can skip config.

Where can I find the stable multithreaded one, then?

[Jamaika]

https://github.com/fraunhoferhhi/vvdec
https://github.com/fraunhoferhhi/vvenc
plus my fix
I have added codecs and compilation issues in my threads

[FranceBB]

https://github.com/fraunhoferhhi/vvdec
https://github.com/fraunhoferhhi/vvenc
plus my fix
I have added codecs and compilation issues in my threads

Thanks!
Last question: from what I see it's still uncompressed .yuv input file only, so I assume a -f yuv4mpegpipe - | from FFMpeg wouldn't work, right?

[hajj_3]

Does anyone know whether an open source optimised VVC software decoder is being made by anyone?

[birdie]

Does anyone know whether an open source optimised VVC software decoder is being made by anyone?

I'm quite sure many companies are already developing coders and decoders behind closed doors but in terms of open source support/solutions it's been dead quiet except for an encoder from Multicoreware which was announced several months ago.

Sharp meanwhile has announced a real time decoder for up to 8K VVC streams: https://global.sharp/corporate/news/201204-a.html I've tried to dig deeper but it looks like the corporation is averse to open source ;-)

[birdie]

Speaking of the reference encoder, vvcenc, it's already quite fast without tons of hand-written optimizations/assembly: https://www.streamingmedia.com/Articles/Editorial/Featured-Articles/How-Does-VVC-Measure-Up-Right-Now-144235.aspx

Looks like when it gets properly optimized it'll be a lot faster than aomenc (though now the reference AV1 encoder is SVT-AV1 which I haven't yet accepted as its quality is quite poor IMO).

[Marsu42]

Looks like when it gets properly optimized it'll be a lot faster than aomenc

That shouldn't be a surprise, should it?

Afafik av1 ist a "simply try everything" encoder, because patented mpeg fast prediction tools aren't included.

So even if vvc has added complexity vs hevc vs avc, it should be still more tuned for fast encoding - while av1 is designed to avoid patents and tuned for either "quality doesn't matter" video calls or "cost doesn't matter' encoding by streaming providers.

[foxyshadis]

That shouldn't be a surprise, should it?

Afafik av1 ist a "simply try everything" encoder, because patented mpeg fast prediction tools aren't included.

So even if vvc has added complexity vs hevc vs avc, it should be still more tuned for fast encoding - while av1 is designed to avoid patents and tuned for either "quality doesn't matter" video calls or "cost doesn't matter' encoding by streaming providers.

I think it's more that AV1 followed a similar trajectory as the messy H.264/AVC spec process, with lots of freewheeling tools and an unmaintainable, unoptimizable codebase. JM was a joke for many years, but with a surprising amount of work it got much better despite not having a market; eventually the HM (H.265/HEVC) used its base to graft new tools on instead of starting from scratch, and H.266/VVC is doing the same with an even more mature and optimized base. What that also means is that you aren't going to see the kinds of staggering differences between JM and an x264 anymore.

AV1 threw out lots of baby with the bathwater in trying for a total do-over of codec development, instead of just building off of VP9, because it ended up so different. (Not the VP9 was any peach.) Other AV1 implementations have tons of freedom to do much better, which is both better and unfortunate. A future AV2 will have the benefit of whatever portion of aom's code and optimizations are reusable. It's not like AV1 finalized pie in the sky proposals, though; just like every MPEG process, there was a painful period of cutting them down to what met a size and performance budget, and that's a huge part of why the final spec was so delayed.

But also, AV1 didn't benefit from the large number of experienced chip designers who weigh in on all MPEG proposals regarding baking it into transistor budgets. C'est la vie.

[hajj_3]

AV1 threw out lots of baby with the bathwater in trying for a total do-over of codec development, instead of just building off of VP9, because it ended up so different. (Not the VP9 was any peach.) Other AV1 implementations have tons of freedom to do much better, which is both better and unfortunate. A future AV2 will have the benefit of whatever portion of aom's code and optimizations are reusable.

Some of the nice things about a future AV2 codec are:

1. lots of patents will have expired.
2. sisvel published a list of patents they claim that av1 violates therefore av2 can be developed to make sure that those aren't violated.
3. unifiedpatents.com have been successfully invalidating some av1 and hevc patents which means that some of those patents will be able to be used.

I do hope that AV2 isn't ratified within 5yrs of AV1 though, otherwise it might make a difficult for AV1 to become popular.

[Jamaika]

Untested info
No video player can show this. Full compatibility can be expected in a year's time!

mp4box.exe -new -info -add import.vvc output.mp4

Codec VVC in conteiner mp4.

Track Importing HEVC - Width 1280 Height 720 FPS 25000/1000 SAR 0/0
VVC Import results: 55 samples (144 NALUs) - 55 SEI - 3 IDR
VVC Stream uses forward prediction - stream CTS offset: 55 frames
VVC Max NALU size is 63768 - stream could be optimized by setting nal_length=2
# Movie Info - 1 track - TimeScale 600
Duration 00:00:00.000 (recomputed 00:00:04.240)
Fragmented: no
Major Brand iso4 - version 1 - compatible brands: iso4
Created: GMT Wed Jan 6 21:02:22 2021


# Track 1 Info - ID 1 - TimeScale 25000
Media Duration 00:00:00.000 (recomputed 00:00:02.200)
Track has 1 edit lists: track duration is 00:00:04.240
Media Info: Language "Undetermined (und)" - Type "vide:vvc1" - 55 samples
Visual Sample Entry Info: width=1280 height=720 (depth=24 bits)
Visual Track layout: x=0 y=0 width=1280 height=720
VVC Video - Visual Size 1280 x 720
VVC Info: Profile 1 @ Level 64 - Chroma Format YUV 4:2:0

NAL Unit length bits: 32
Parameter Sets: 1 SPS 1 PPS
Bit Depth 8 - 5 temporal layers
SPS#1 hash: CD7EE785B89AF3327C233B50CA28C755D751EAFA
PPS#1 hash: FF54700DA8418365C4BB4330DEE1EF986AA37AAC

RFC6381 Codec Parameters: vvc1.1.L64
Average GOP length: 27 samples
Max sample duration: 0 / 25000

0.500 secs Interleaving

[FranceBB]

Sweet, so it's possible to mux in mp4 as well and not just mkv. Good.
Apart from the container, is there any player at all (beside the DecoderApp.exe) that can play VVC files?
And last but not least: any news from Multicoreware about x266?

[quietvoid]

There seems to be a x266 repo on MCW's Bitbucket since October or something, but it's still private.

[FranceBB]

There seems to be a x266 repo on MCW's Bitbucket since October or something, but it's still private.

I see! So they're waiting to get things going before opening to open source. Well, it kinda makes sense, I think...

[birdie]

ffmpeg hasn't even begun adding support for VVC. That looks weird, the codec uptake seems to be extremely slow.

[Jamaika]

What is this talking about?
GPAC did what it could. I exerted pressure. There aren't resources for modifying new codecs in GPAC jpeg2000, avif, heif.
I remind you that in jpeg.org propaganda heif photos can contain and convert to HTJPEG2000. It is fantasy right now. There are no funds or there are paid programs somewhere.
https://jpeg.org/jpeg2000/index.html
JPEGXS will not come out free this year. It was supposed to be the successor to jpeg2000.
https://www.iis.fraunhofer.de/en/ff/amm/content-production/jpegxs.html
https://www.intopix.com/ffmpeg
Google codecs are for google and the rest don't count. The rest as competition will not support google.
The mpeg5 container had new features mainly anti-piracy in the network under vvc, evc codecs. The strange thing is we have mp4 and matroska from vvc. SONY is sure to be happy as he fought with matroska.
https://github.com/MPEGGroup/isobmff
The creators of m-ad-s laughed at me with the answer. Write better, create your own library, but they advertise google codec aom.
https://github.com/m-ab-s/media-autobuild_suite/commits/master

[Jamaika]

x266 Open-Source Encoder for VVC by MulticoreWare
https://ottverse.com/x266-vvc-multicoreware-opensource-encoder/
If you have any questions for the MulticoreWare team, please get in touch with Shivakumar Narayanan at x266@multicorewareinc.com.

[Jamaika]

Untested
Main Features
Spliting video by scenes for parallel encoding because AV1 encoders are currently not good at multithreading, encoding is limited to single or couple of threads at the same time.

PySceneDetect used for spliting video by scenes and running multiple encoders.
Fastest way to encode AV1 without losing quality, as fast as many CPU cores you have :).
Target Quality mode. Targeting end result reference visual quality. VMAF used as substructure
Resuming encoding without loss of encoded progress.
Simple and clean console look.
Automatic detection of the number of workers the host can handle.
Building encoding queue with bigger files first, minimizing waiting for the last scene to encode.
Both video and audio transcoding with FFmpeg.
Logging of progress of all encoders.
Install
Prerequisites:

Install Python3
When installing under Windows, select the option add Python to PATH in the installer
Install FFmpeg
Recommended to install vapoursynth with lsmash for faster and better processing
Encoder of choice:

Install AOMENC
Install rav1e
Install SVT-AV1
Install SVT-VP9
Install vpx VP9, VP8 encoding
Install VTM VVC encoding test model
Optional :

Vapoursynth
ffms2
lsmash
mkvmerge
If someone compiles, let him praise it. :)
https://github.com/master-of-zen/Av1an

[FranceBB]

x266 Open-Source Encoder for VVC by MulticoreWare
https://ottverse.com/x266-vvc-multicoreware-opensource-encoder/

Well, it really just says:


For the larger open source community, it will be made available when we have reached critical mass required for its first release. As we near readiness, we will update here on how you can get hold of it.


so, again, they're working on it, but we can't see it yet, so all we have is the encoder_app.exe reference encoder

[Jamaika]

so, again, they're working on it, but we can't see it yet, so all we have is the encoder_app.exe reference encoder
There is actually something, but I don't know what it is.
For sure gcc won't compile.
What language will it be in? It is not known.
The creator dreams of x266, but currently works in vvc.
I don't know what single file x266.cpp files are. There is probably some assembler.
https://github.com/chenm001/x266
https://github.com/fraunhoferhhi/vvdec/commits?author=chenm001
The ?266's RISC-V NON-Standard Vector Extension ONLY compile and disassembly by ?266 project modified llvm suite. You may build bu yourself or please contract to get prebuilt Centos-6 binary package.

[FranceBB]

Well, I contacted Multicoreware anyway with my Sky email, asking them for some info.
Let's see if they reply.

[ksec]

ffmpeg hasn't even begun adding support for VVC. That looks weird, the codec uptake seems to be extremely slow.

The spec is barely out. Finalised last August, but profiles were still not set then. VTM Reference Software was barely catching up in October and VTM 11.0 only released two days ago. Conformance test wasn't finalised either.

I mean normally these sort of "cleaning up" takes up to a year. So I think they are doing well so far.

[MeteorRain]

Cutting edge technologies take time to be implemented.
22.2 channel aac audio spec was released years ago, and we barely just had a preliminary support in the latest version, implemented by jeeb.
Sometimes you have to be patient ;)

[Jamaika]

ffplay's humble beginnings
https://github.com/FFmpeg/FFmpeg/commit/ebdd33086adc9899959840b616480c42c80653ce#diff-8d19749c083bc0060b37a7e4e22171de76da06f51836f41f96ee630d53c30d3f

[FranceBB]

ffplay's humble beginnings
https://github.com/FFmpeg/FFmpeg/commit/ebdd33086adc9899959840b616480c42c80653ce#diff-8d19749c083bc0060b37a7e4e22171de76da06f51836f41f96ee630d53c30d3f

That is indeed something!
Having a decoder is basically the first thing you want when supporting a codec, so those commits are more than welcomed. :)

[FranceBB]

https://github.com/fraunhoferhhi/vvdec
https://github.com/fraunhoferhhi/vvenc
plus my fix
I have added codecs and compilation issues in my threads

I'm clearly doing something wrong.

Selecting Windows SDK version 10.0.18362.0 to target Windows 10.0.19042.
The C compiler identification is MSVC 19.27.29112.0
The CXX compiler identification is MSVC 19.27.29112.0
Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.27.29110/bin/Hostx64/x64/cl.exe
Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.27.29110/bin/Hostx64/x64/cl.exe - works
Detecting C compiler ABI info
Detecting C compiler ABI info - done
Detecting C compile features
Detecting C compile features - done
Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.27.29110/bin/Hostx64/x64/cl.exe
Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.27.29110/bin/Hostx64/x64/cl.exe - works
Detecting CXX compiler ABI info
Detecting CXX compiler ABI info - done
Detecting CXX compile features
Detecting CXX compile features - done
CMAKE_MODULE_PATH: updating module path to: C:/Users/Frank/Desktop/vvenc-master/cmake/modules
Looking for pthread.h
Looking for pthread.h - not found
Found Threads: TRUE
Configuring done
Generating done

https://i.imgur.com/XdXGsCB.png
https://i.imgur.com/2wdONHk.png
https://i.imgur.com/AxLcvTC.png
https://i.imgur.com/NPgTz4m.png
https://i.imgur.com/AP5xg3z.png

[Jamaika]

New codecs VVC
https://www.sendspace.com/file/09xyse

[FranceBB]

New codecs VVC
https://www.sendspace.com/file/09xyse

Thank you for building it for me! I'll test it on Monday as soon as I'll get back to work! :D

[Jamaika]

The Streaming Codec Landscape in 2021 (https://www.wowza.com/blog/streaming-codec-landscape-2021)
What Happened in 2020?
This past year saw the launch of two MPEG codecs — VVC and Low Complexity Enhancement Video Coding (LCEVC) — and the continued development of Essential Video Coding (EVC). You can read more about VVC’s technical background here. I reviewed Fraunhofer’s VVC encoder and decoder, respectively called VVenC and VVdeC, for Streaming Media Magazine here. As Table 2 shows, VCVenC proved 39% more efficient than x265 in terms of quality, but it took 10x longer to encode, and it was 3.7x slower during decode.

Regarding royalties, the intellectual property that was contributed to VVC came from many parties, and VVC will be royalty-bearing, although we probably won’t know what the royalty policy will look like until mid-2021 or later.

[benwaggoner]

The Streaming Codec Landscape in 2021 (https://www.wowza.com/blog/streaming-codec-landscape-2021)
What Happened in 2020?
This past year saw the launch of two MPEG codecs — VVC and Low Complexity Enhancement Video Coding (LCEVC) — and the continued development of Essential Video Coding (EVC).
An error in the quoted statement here - LCEVC isn't a codec. It's a standardized postprocessing with metadata technology that sits on top of codecs. It could be applied to H.264, HEVC, and/or VVC.

[Jamaika]

An error in the quoted statement here - LCEVC isn't a codec. It's a standardized postprocessing with metadata technology that sits on top of codecs. It could be applied to H.264, HEVC, and/or VVC.
Is LCEVC mpeg5 paid? I don't see free libraries, and the final standard was in October 2020.
https://www.lcevc.org/
Weird. nothing is said about the new AV2 codec.
https://www.programmersought.com/images/110/fcf500c777166b3532682cd3f536ec0e.png

[hajj_3]

Is LCEVC mpeg5 paid? I don't see free libraries, and the final standard was in October 2020.
https://www.lcevc.org/
Weird. nothing is said about the new AV2 codec.
https://www.programmersought.com/images/110/fcf500c777166b3532682cd3f536ec0e.png
Interestingly that image from ateme shows that AV2 will be ratified in ~2026. I haven't seen a timeline for AV2 before. I'm glad they aren't going to try and release a new one every 3 years which i think was the original intention. This way AV1 will have time to become popular. Also nearly all the h264 patents will have expired by then. I'm sure that some of the patents that Sisvel claim AV1 violates will have expired by then too.

[ksec]

Interestingly that image from ateme shows that AV2 will be ratified in ~2026. I haven't seen a timeline for AV2 before. I'm glad they aren't going to try and release a new one every 3 years which i think was the original intention. This way AV1 will have time to become popular. Also nearly all the h264 patents will have expired by then. I'm sure that some of the patents that Sisvel claim AV1 violates will have expired by then too.

Giving too much credit for Google or Alliance Open Media, their original goal was new codec every "2" years. /s

Speaking of H264 patents, I am eagerly waiting for the patent free EVC baseline to test. Which is pretty much all H.264 expired or soon to be expired patents.

[benwaggoner]

Giving too much credit for Google or Alliance Open Media, their original goal was new codec every "2" years. /s

Speaking of H264 patents, I am eagerly waiting for the patent free EVC baseline to test. Which is pretty much all H.264 expired or soon to be expired patents.
There are certainly people interested in getting AV2 standardized before 2026. VVC's technical superiority over AV1 is pretty substantial. And essential patents are expiring every year, so there are plenty of techniques that couldn't be implemented in AV1 that are already available for AV2.

[hajj_3]

BAD NEWS GUYS... The Media Coding Industry Forum (MC-IF) whose members make up the majority of VVC patents have been unable to achieve concencus in picking a patent licensing pool administrator so there will be 2 PATENT POOLS!!!!! One of the pools is 'Access Advance', the other is 'MPEG-LA'. Source: https://a7dce6fd-e8f0-45f7-b0b0-255c5c9a28e1.filesusr.com/ugd/0c1418_a055f01edeba4e0abe7a1c0482debab7.pdf

Clearly they haven't learnt their lesson from the HEVC patent licensing problems!

[ksec]

LOL, It is Access Advance ( Previously HEVC Advance ) and MPEG LA again. I am starting to think there are some bad blood between the two.

And even Google is part of Access Advance Licensor.

Despite the public hatred against MPEG-LA, they have been the one offering cheaper HEVC licensing.

[FranceBB]

Yeah... this is not good news for general availability...
Let's see how it's gonna play out...

[ksec]

Yeah... this is not good news for general availability...
Let's see how it's gonna play out...

Well We are only 1 year away from 3nm. Whatever cost, power or other obstacles AV1 had with mobile hardware decoder will diminish with the advance of computing and design.

[excellentswordfight]

Well We are only 1 year away from 3nm. Whatever cost, power or other obstacles AV1 had with mobile hardware decoder will diminish with the advance of computing and design.
TSMC 5nm node has higher transistor cost then 7nm, and 3nm will probably follow that trend, so not sure how 3nm will help if the reason for the lack of av1 decoders was cause of roi on transistor budget.

Edit. initially ofc, but the trend is that transistor cost isnt drastically reduced anymore from die shrinks.

[ksec]

TSMC 5nm node has higher transistor cost then 7nm, and 3nm will probably follow that trend, so not sure how 3nm will help if the reason for the lack of av1 decoders was cause of roi on transistor budget.

Edit. initially ofc, but the trend is that transistor cost isnt drastically reduced anymore from die shrinks.

If you are comparing non EUV 7nm aka N7, then barely. Otherwise no. ( EUV 7nm and EUV 5nm. ) Wafer Price are on the rise and per transistor cost isn't yet. It is not hitting the same cost reduction but per transistor cost has never risen per generation during their time of introduction.

Design Cost is the main factor in cost increase, but that bare little relevance to unit cost without specific volume accounted for.

5nm and 3nm are relevant not only because of cost but Die Space and Power Usage. Where in Mobile devices you are expecting a budget of sub 100mW for Decoding. In Laptop you have the luxury of budget increase by 10x / 1W if not more on a GPU.

[hajj_3]

MPEG-LA has released a press release about their VVC patent pool: https://www.mpegla.com/wp-content/uploads/FINAL-VVC-PID-PrsRls-2021-01-27.pdf

[excellentswordfight]

If you are comparing non EUV 7nm aka N7, then barely. Otherwise no. ( EUV 7nm and EUV 5nm. ) Wafer Price are on the rise and per transistor cost isn't yet. It is not hitting the same cost reduction but per transistor cost has never risen per generation during their time of introduction.

Design Cost is the main factor in cost increase, but that bare little relevance to unit cost without specific volume accounted for.

5nm and 3nm are relevant not only because of cost but Die Space and Power Usage. Where in Mobile devices you are expecting a budget of sub 100mW for Decoding. In Laptop you have the luxury of budget increase by 10x / 1W if not more on a GPU.
I was talking about the non euv N7 node, as its rumored that 5nm wafer price was 1.8x higher, while comparing something like apples a12 to a14, density ”only” increased by 1.5x.

But thats intresting, but to me it sounds a bit odd... ”We cannot make an sub 100mW decoder on current silicon so lets use software decoding instead!” :)

I though that the key factor was that they didnt wanna waste money on silicon for an feature that might not see wide adoption, and that av1 needed quite a bit of silicon budget.

[benwaggoner]

I though that the key factor was that they didnt wanna waste money on silicon for an feature that might not see wide adoption, and that av1 needed quite a bit of silicon budget.
I've heard estimates that an AV1 decoder can take twice the silicon budget of a VVC decoder. That extra cost of AV1 HW support is likely higher than any savings from not having a per-decoder licensing fee.

[GTPVHD]

https://www.streamingmedia.com/Articles/News/Online-Video-News/VVC-Patent-Pools-And-Then-There-Were-Two-144949.aspx

VVC is dead on arrival as many have predicted.

[Funky080900]

https://www.streamingmedia.com/Articles/News/Online-Video-News/VVC-Patent-Pools-And-Then-There-Were-Two-144949.aspx

VVC is dead on arrival as many have predicted.

“Note that two pools aren't necessarily a bad thing; many successful technology standards involve multiple pools”

The article doesn't say that VVC is dead only that “potential licensees won't know total VVC royalty costs until both pools release their royalty terms”

[ksec]

“Note that two pools aren't necessarily a bad thing; many successful technology standards involve multiple pools”

The article doesn't say that VVC is dead only that “potential licensees won't know total VVC royalty costs until both pools release their royalty terms”

Access Advance already have some preliminary announcement [1] with regards to pricing a long time ago. Considering they are making it a HEVC + VVC pool, you can bet it won't be cheaper than HEVC. It will be at best, the same as current HEVC pricing but also includes VVC.

And again, ValosMedia, or specifically Qualcomm. Given all other members of Valos are already in either MPEG LA or Access, Qualcomm are not in any the pools ( yet ).

[1] https://accessadvance.com/hevc-advance-releases-draft-vvc-licensing-program-overview-includes-a-joint-vvc-and-hevc-license/

[benwaggoner]

“Note that two pools aren't necessarily a bad thing; many successful technology standards involve multiple pools”

The article doesn't say that VVC is dead only that “potential licensees won't know total VVC royalty costs until both pools release their royalty terms”
HEVC has three pools, and certainly isn't dead. The licensing situation is Not Good, certainly, but pretty much every device you've bought in the last 4-5 years has a HW HEVC decoder.

[foxyshadis]

I've heard estimates that an AV1 decoder can take twice the silicon budget of a VVC decoder. That extra cost of AV1 HW support is likely higher than any savings from not having a per-decoder licensing fee.

I wonder how much of the spec they implement, since nothing has trickled down for consumers to test yet. AV1 bucks the general trend of having a very stripped-down baseline MPEG profile that hardware can implement; its baseline includes most of the more complex tools and colorspaces that hardware pretends don't exist and therefore the state of the art never really budges as much as you'd expect.

[benwaggoner]

I wonder how much of the spec they implement, since nothing has trickled down for consumers to test yet. AV1 bucks the general trend of having a very stripped-down baseline MPEG profile that hardware can implement; its baseline includes most of the more complex tools and colorspaces that hardware pretends don't exist and therefore the state of the art never really budges as much as you'd expect.
Yeah, it's a tradeoff. It's awesome we can do 444 10-bit in the baseline decoder, but that definitely bumps up complexity. That alone requires 2.5x the sample fill rate of 420 8-bit.

MPEG has been great at making very thoughtful choices to optimize for HW decoder complexity, but AV1 didn't get nearly the breadth of input about HW implementations, and efforts were very much focus on SW decoders for a long time.

[hajj_3]

VTM 12.0 is out.

[LigH]

New upload: VTM Encoder Version 12.0 [Windows][GCC 10.2.0][64 bit] (http://www.mediafire.com/file/6ithw8upfn331et/VVCSoftware_VTM-12.0_091d3bb5.7z/file) 091d3bb5

[birdie]

vvenc developers have no plans (https://github.com/fraunhoferhhi/vvenc/issues/59) for supporting lossless compression or anything other than YUV420. Bummer.

[FranceBB]

Oh that's disappointing...
I guess we will have to wait for Multicoreware to release x266 then...
Any news on that regard?

[Marsu42]

vvenc developers have no plans (https://github.com/fraunhoferhhi/vvenc/issues/59) for supporting lossless compression or anything other than YUV420. Bummer.

Actually, it says "The support is not planned in the near future." - which makes sense because they would want to get basic vvc support ready first, and not code/ optimize/ debug multiple bit depths or lossless at the same time.

[Jamaika]

New codec VVC 12.3 / VVENC 0.3.1 2021.05.14 + JVET_V0061 + JVET_V0106 + test files video
https://www.sendspace.com/file/aayebk

[birdie]

Actually, it says "The support is not planned in the near future." - which makes sense because they would want to get basic vvc support ready first, and not code/ optimize/ debug multiple bit depths or lossless at the same time.

There are relatively few users of lossless and they don't care much e.g. about speed, so I'd be glad if they just implemented it based on the algos already in place and continue to optimize the code base for lossy encoding.

[benwaggoner]

There are relatively few users of lossless and they don't care much e.g. about speed, so I'd be glad if they just implemented it based on the algos already in place and continue to optimize the code base for lossy encoding.
Yeah, lossless mode is quite different and also less complex than lossy encoding. https://x265.readthedocs.io/en/master/lossless.html

A nice feature of HEVC and VVC is the ability to use lossless coding units selectively in a lossy stream. Lossless can compress stuff like a black/white checkerboard more efficiently than any frequency transform.

[LigH]

New upload: VTM Encoder Version 13.0rc1 [Windows][GCC 10.3.0][64 bit] (https://www.mediafire.com/file/xlj2l317y7s9mch/VVCSoftware_VTM-13.0rc1_8b3e24da.7z/file) 8b3e24da

[HowaWe]

Thanks. VVenC v1.0.0 released...

https://github.com/fraunhoferhhi/vvenc/releases/tag/v1.0.0

[birdie]

I want to believe an alpha release of x266 is imminent, as MulticoreWare has almost completely ceased the development of x265 - the last commit is almost two months old.

[FranceBB]

I want to believe an alpha release of x266 is imminent, as MulticoreWare has almost completely ceased the development of x265 - the last commit is almost two months old.

I very much hope so...
I've been waiting for this since 2018... eheheheheh

[Jamaika]

Decoder OpenVVC 0.2.0-954f2fc for ffmpeg
https://github.com/OpenVVC/OpenVVC
openvvc.exe -l 6 -i image1.266 -o image1.yuv

[ksec]

Comparative Rate-Distortion-Complexity Analysis of VVC and HEVC Video Codecs

https://ieeexplore.ieee.org/document/9420710

Doesn't look good to me. ><

[birdie]

Comparative Rate-Distortion-Complexity Analysis of VVC and HEVC Video Codecs

https://ieeexplore.ieee.org/document/9420710

Doesn't look good to me. ><

Looks fine to me: On the other hand, the results show that the complexity overhead of VTM is very stable, around 1.8× under all test conditions.

That's a lot better than AV1 (hw decoder) which is already implemented in HW in millions of devices.

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

[ksec]

Looks fine to me: On the other hand, the results show that the complexity overhead of VTM is very stable, around 1.8× under all test conditions.

That's a lot better than AV1 (hw decoder) which is already implemented in HW in millions of devices.

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

I initially skim read it and only read the All Infra and PSNR section and the total average. Turns out the others were all getting 40%+. So that is certainly good enough in my book.

And Complexity is much much better.

[hajj_3]

HEVC HM 16.15 vs VVC VTM-12.0:

https://www.elecard.com/storage/images/Technology/VideoSolutions/VVC_BQMall.jpg

https://www.elecard.com/storage/images/Technology/VideoSolutions/VVC_BasketballDrill.jpg

source: https://www.elecard.com/page/a_review_of_the_vvc_codec

[birdie]

No idea where to post it, so I'll leave it in this topic. Here's an interesting sequence (https://mega.nz/folder/j4sgiDSZ#fa2viTooGHN6gvN1PgOpBw) to test video compression. Totally free to redistribute or do absolutely anything with it. The second file/tar archive contains a par2 recovery record and checksums.

[benwaggoner]

And for anyone looking for new free stress test content, I can't recommend Netflix's Sol Levante enough. It's CGI HDR 4K anime, which is something no encoder ever has been tuned for, and it reveals all sorts of interesting problems.

http://download.opencontent.netflix.com/?prefix=SolLevante/

I made a 1080p SDR downconversion I should share.

[benwaggoner]

No idea where to post it, so I'll leave it in this topic. Here's an interesting sequence (https://mega.nz/folder/j4sgiDSZ#fa2viTooGHN6gvN1PgOpBw) to test video compression. Totally free to redistribute or do absolutely anything with it. The second file/tar archive contains a par2 recovery record and checksums.
Yeah, a lot of challenge in there. And Rec 2020 primaries but Rec. 709 EOTF? Where did it come from?

And any chance you could make a x265 --lossless version of it from uncompressed source? Even at 120 Mbps I'd expect H.264 to still have some low-pass filtering.

[birdie]

Yeah, a lot of challenge in there. And Rec 2020 primaries but Rec. 709 EOTF? Where did it come from?

And any chance you could make a x265 --lossless version of it from uncompressed source? Even at 120 Mbps I'd expect H.264 to still have some low-pass filtering.

From my smartphone :-) This is the only source and if people find it useful, great, otherwise I've already deleted it from my PC.

I'm not even sure it's good for for testing codecs, as SnapDragon 845 hardware H.264 codec might not compress without major issues.

[FranceBB]

Masterfiles coming from proper cameras should be saved as .dng lossless which is essentially a sequence of frames (each frame is a picture in .dng) saved in a folder with PCM audio in wav saved in another folder.
Generally, external encoders are connected to the camera either via SDI or via other means...
From there, any kind of other lossless video can be encoded and from that tests are generally made.
Anyway, it's kind of you that you submitted a clip and please feel free to continue, the more the merrier, but I would consider a proper interesting test something coming from a RED Monstro or an Arri Alexa etc

[Emulgator]

Oh, efficiency. Which side do we choose ? Let's count cycles.
5 years encoding time on a 4000$ server CPU just for the review...
The VVC table 8 shows 400..1400kcpp = 0,4..1,4Mcpp.
Let's go for 1Mcpp at decent quality and do the math:
FHD: ~2.000.000.000.000 cpf, ~48.000.000.000.000 cps @24fps, ~120.000.000.000.000 cps @60fps
4kUHD: ~8.000.000.000.000 cpf, ~192.000.000.000.000 cps @24fps, ~480.000.000.000.000 cps @60fps
8kUHD: ~32.000.000.000.000 cpf, ~768.000.000.000.000 cps @24fps, ~1.920.000.000.000.000 cps @60fps.
On which CPU farms are people betting. Even if only 50 electrons per gate got to be moved: Who is gonna pay that bill ?
30-fold complexity over H.265 for a rate gain of -30..40% (which had a complexity price of 10-fold over H.264 for a rate gain of -30..40%)
Such future must be bright, but for whom...

[FranceBB]

Such future must be bright, but for whom...

For Energy Companies xD

[ksec]

Oh, efficiency. Which side do we choose ? Let's count cycles.
5 years encoding time on a 4000$ server CPU just for the review...
The VVC table 8 shows 400..1400kcpp = 0,4..1,4Mcpp.
Let's go for 1Mcpp at decent quality and do the math:
FHD: ~2.000.000.000.000 cpf, ~48.000.000.000.000 cps @24fps, ~120.000.000.000.000 cps @60fps
4kUHD: ~8.000.000.000.000 cpf, ~192.000.000.000.000 cps @24fps, ~480.000.000.000.000 cps @60fps
8kUHD: ~32.000.000.000.000 cpf, ~768.000.000.000.000 cps @24fps, ~1.920.000.000.000.000 cps @60fps.
On which CPU farms are people betting. Even if only 50 electrons per gate got to be moved: Who is gonna pay that bill ?
30-fold complexity over H.265 for a rate gain of -30..40% (which had a complexity price of 10-fold over H.264 for a rate gain of -30..40%)
Such future must be bright, but for whom...

Before AV1 was a thing, one of the engineers from a founding member of Alliance for Open Media went to I think it was either MPEG or VCEG trying to shape the next generation of Video Codec. Where they told the committee they have "budget" of 1000x the encoding complexity.

I actually dont mind complexity, if you can reduce a 4Mbps H,264 file to 400kbps at the same quality I am all for a 1000x increase. Unfortunately we dont.

It also with noting 30x doesn't mean you need 30x the die size or transistors for encoding. So from an Hardware prospective it is not that bad.

[Jamaika]

Performance Overview of the Latest Video Coding Proposals: HEVC, JEM and VVC (https://www.mdpi.com/2313-433X/7/2/39/pdf)

[RanmaCanada]

Performance Overview of the Latest Video Coding Proposals: HEVC, JEM and VVC (https://www.mdpi.com/2313-433X/7/2/39/pdf)

Why would they use a system with a CPU that is over a decade old?

The platform was an HP Proliant SL390 G7 of which only one of the Intel Xeon X5660 processors was used and the compiler was GCC v.4.8.5. At least use something with AVX2.

I feel that this comparrison is useless as it's not even a real world scenario. Extremely frustrating.

[rwill]

Why would they use a system with a CPU that is over a decade old?

The platform was an HP Proliant SL390 G7 of which only one of the Intel Xeon X5660 processors was used and the compiler was GCC v.4.8.5. At least use something with AVX2.

I feel that this comparrison is useless as it's not even a real world scenario. Extremely frustrating.

The comparison is perfectly valid as all tested softwares worked within the same constraints. In this case no AVX2 is a plus too.

[RanmaCanada]

The comparison is perfectly valid as all tested softwares worked within the same constraints. In this case no AVX2 is a plus too.

I personally feel it is not as different IPC and different extensions will greatly affect the encoder speeds. Also, who still uses a x5660 as an encoder box? We know that AVX2 greatly increases the efficiency of HEVC, as we see the difference between zen+ and zen2. I just feel that this test is not even close to a real world situation, and it would be like testing modern video games on a gt210 and then claiming such complexities.

You can not extrapolate what a real world result would be from the conditions that were used.

[ksec]

Performance Overview of the Latest Video Coding Proposals: HEVC, JEM and VVC (https://www.mdpi.com/2313-433X/7/2/39/pdf)

I am very angry. As I notice the BD Rate differences and decided to dig a little bit. But just before I absolute rant. Forgive me.

May be someone could explain to me, in a 2021 paper,

Why are they using JEM 3.0 and VTM 1.1, software that were from 3+ years ago?

[ksec]

I personally feel it is not as different IPC and different extensions will greatly affect the encoder speeds. Also, who still uses a x5660 as an encoder box? We know that AVX2 greatly increases the efficiency of HEVC, as we see the difference between zen+ and zen2. I just feel that this test is not even close to a real world situation, and it would be like testing modern video games on a gt210 and then claiming such complexities.

You can not extrapolate what a real world result would be from the conditions that were used.

They are all reference encoder and wouldn't have included any SIMD optimisation anyway. ( Apart from VTM )
So you have the same baseline to compare their inherent complexity.

[RanmaCanada]

I am very angry. As I notice the BD Rate differences and decided to dig a little bit. But just before I absolute rant. Forgive me.

May be someone could explain to me, in a 2021 paper,

Why are they using JEM 3.0 and VTM 1.1, software that were from 3+ years ago?

For the same reason they are using hardware that's from 10+ years ago?

[Jamaika]

I posted the codec test because someone did something there. Probably the mega-data flow on the satellite. Nothing is said about amateur. As for the profession of filmmaker, editor. I see that a professional changes the processor every six months to a newer one to make it faster. The question is whether the movie is better. No, money matters here. What is the quality of the camera optics and filming technique? Does software such as Adobe Premiere keep up with the news of all graphics cards? I do not think so.
What about SIMD? VTM / AOM codecs have SIMD. The problem is that they are only for Windows 32bit.

[birdie]

I am very angry. As I notice the BD Rate differences and decided to dig a little bit. But just before I absolute rant. Forgive me.

May be someone could explain to me, in a 2021 paper,

Why are they using JEM 3.0 and VTM 1.1, software that were from 3+ years ago?

I can't. Let's just pay this paper no attention and move on. :)

[ksec]

I can't. Let's just pay this paper no attention and move on. :)

Ok. :)

[benwaggoner]

I personally feel it is not as different IPC and different extensions will greatly affect the encoder speeds. Also, who still uses a x5660 as an encoder box? We know that AVX2 greatly increases the efficiency of HEVC, as we see the difference between zen+ and zen2. I just feel that this test is not even close to a real world situation, and it would be like testing modern video games on a gt210 and then claiming such complexities.

You can not extrapolate what a real world result would be from the conditions that were used.
Absolutely. Because real world codecs have a lot of variation in how well they can take advantage of paralleism and SIMD. And reference encoders comparisons tend to use quite exhaustive searches without the many early-exit heuristics that make real-world encoders fast enough for production use. That has real-world impact! While single-thread C-only x264 is MUCH faster than x265, when you've got a many core AVX2 capable CPU, the gap is much smaller, because H.264 just can't productively use that many threads and that wide SIMD.

Nor do reference comparison tests have the psychovisual tuning that real-world encoders use to make for good subjective quality across a wide range of content possible. Adaptive quantization, adaptive frame types, and VBV rate control are essential to a production encoder but not evaluated in reference comparisons.

The tools for that kind of psychovisual tuning aren't stressed in reference comparisons, and have a huge real-world impact. A big reason that VC-1 didn't have long-term viability against H.264 was that the adaptive QP signaling syntax in VC-1 was just a RLE of QP offsets. The overhead of doing that for most blocks in a frame was so high that it reduced how many bits were available for actually encoding those blocks. H.264 had a much more efficient syntax which made lots of intra-frame variation much more feasible.

AV1's requirement to not use any IP that was patented meant that lots of its tools weren't the optimal ones to do. So they wound up with ones with lots of potential variations to test, and ones that are expensive to decode and so expensive to try alternatives of. Which is why all the examples of "AV1 is better than HEVC" tend to be 10% lower bitrates on VMAF at >10x the encoding time. That's stuff that reference comparisons don't pick up on, but are very important to real-world viability.

And since AV1 was tuned using VMAF, it gets higher VMAF scores for the same subjective quality, and so VMAF is a worse tool to evaluate with. Once any metric is demonstrate to have good subjective correlation and starts to get used to make codec and encoder decisions, developers start optimizing for the metric directly instead of for the thing the metric is attempting to capture. And thus the subjective correlation and value of any given metric goes down the more it is optimized for. The VMAF ML model would be quite different if it were trained on MOS scores of AV1 encoded content instead of just x264.


Reference encoder comparisons have some value, and are the best we can do in early-stage codec development. But they are pretty limited in how accurately we can extrapolate real-world implementation capabilities.

[hajj_3]

https://spin-digital.com/announcements/vvc-player/

[birdie]

Some news:

1 (https://www.allegrodvt.com/allegro-dvt-launches-the-worlds-first-vvch-266-decoder-silicon-ip/)

Allegro DVT Launches the World’s First Hardware-Based VVC/H.266 Decoder Silicon IP

Allegro DVT, the leading provider of video processing silicon IPs, today announced the immediate availability of its AL-D320 video decoder semiconductor IP core supporting the latest Versatile Video Coding (VVC/H.266) format. The AL-D320 core is the world’s first hardware IP to support the new VVC format with 8, 10 and 12-bit samples, chroma sampling of 4:2:0 and 4:2:2 and image resolutions and rates of up to 8K120. Added to this, the core continues to support H.264 and HEVC up to 12-bit and 4:4:4 chroma subsampling.

AL-D320 decoder IP is immediately available for integration by SoC vendors in various technology nodes ranging from 28nm down to 5nm and below through a seamless and proven HW and SW integration kit.


2 (https://www.prnewswire.com/news-releases/access-advance-launches-vvch266-video-patent-pool-301323570.html)

Access Advance Launches VVC/H.266 Video Patent Pool

Building on the success of its HEVC Advance Patent Pool, Access Advance today announced the launch of the VVC Advance Patent Pool and the Multi-Codec Bridging Agreement ("MCBA"). VVC is the next generation video codec standard finalized less than one year ago, which provides significant improvements in video compression of up to 50% over HEVC, enabling a new generation of products, ever more beautiful video, faster downloads, and improved savings on storage.

The license structure of the new VVC Advance Pool mirrors that of the HEVC Advance Platform Pool License recently announced, with royalty rates and caps set at a modest 25% increase over the equivalent HEVC Advance License structure. Please see https://www.accessadvance.com/vvc-advance-patent-pool-royalty-rates-summary

Importantly, as requested by the marketplace, Licensees that have executed both the HEVC Advance and VVC Advance Platform Licenses will have the option to enjoy the benefits of the MCBA. The MCBA is not a third license; it is an agreement that bridges the HEVC Advance and VVC Advance Platform Licenses. Those Licensees who have executed all three agreements will enjoy a discounted royalty rate for their products that include both VVC and HEVC, paying the same royalty rate as they would pay for a product that includes only VVC, providing an effective 45% discount.

[amehri]

Hello everyone,

I want to optimize VVC decoder, I work with VTM 10. I have to understand the VTM decoder Code. Any suggestion, please!! (VTM code description with details).

[hajj_3]

The VVC advance fees look reasonable. The mpeg-la haven't been published yet though.

[ksec]

Some news:

1 (https://www.allegrodvt.com/allegro-dvt-launches-the-worlds-first-vvch-266-decoder-silicon-ip/)




2 (https://www.prnewswire.com/news-releases/access-advance-launches-vvch266-video-patent-pool-301323570.html)


I was originally upset at the new Cap for VVC and MCBA being too high, now I have done some napkins maths it turns out they were likely targeting some outliner like Apple or Samsung.

But basically $0.5 per devices if you have a VVC logo. And that is excluding MPEG-LA terms.

[benwaggoner]

I was originally upset at the new Cap for VVC and MCBA being too high, now I have done some napkins maths it turns out they were likely targeting some outliner like Apple or Samsung.

But basically $0.5 per devices if you have a VVC logo. And that is excluding MPEG-LA terms.
I also like that the VVC license includes HEVC, so it's a small incremental extra cost for a device that already supports HEVC. It'd be more adoption friction if HEVC and VVC had to be paid independently if both were used.

[hajj_3]

the 1st vvc hardware decoder ip block has been announced: https://www.businesswire.com/news/home/20210630005791/en/Allegro-DVT-Launches-the-World%E2%80%99s-First-Hardware-Based-VVCH.266-Decoder-Silicon-IP

[Jamaika]

New player video YUView for VVC
https://ient.github.io/YUView/

[benwaggoner]

New player video YUView for VVC
https://ient.github.io/YUView/
Nice catch! Has some nice visualizations.

[Jamaika]

Unofficial plugin for VLC player. I don't know if it works.
https://github.com/InterDigitalInc/VTMDecoder_VLCPlugin

[hajj_3]

vvc royalty report by unified patents: https://www.scribd.com/document/515808237/VVC-Report-Public

[ksec]

vvc royalty report by unified patents: https://www.scribd.com/document/515808237/VVC-Report-Public

Read it, ReRead it. Still couldn't understand.

VVC FRAND per-unit Royalty Rate = $0.05.

Basically they are saying Bandwidth cost has decreased so much the "value" of the codec over AVC / H.264 as anchor point as becomes negligible.

I dont even know where to begin.

[benwaggoner]

Read it, ReRead it. Still couldn't understand.

VVC FRAND per-unit Royalty Rate = $0.05.

Basically they are saying Bandwidth cost has decreased so much the "value" of the codec over AVC / H.264 as anchor point as becomes negligible.

I dont even know where to begin.
Yeah. Bandwidth savings are just part of the value of newer codecs. Being able to improve quality of service to lower bandwidth customers is also huge. And helping customers watch more content under their capped/metered bandwidth is also important. There are also material costs to higher bitrates in content encoding, storage, and CDN cache consumption (lower bitrates means more minutes of content can be cached at the edge).

Also, the claimed compression efficiency advantages of AV1 really haven't been proven out with double-blind subjective evaluation with real-world encoding scenarios.

Unified Patents does lots of important work, but I'm not so thrilled by this analysis.

[hajj_3]

Unified Patents does lots of important work, but I'm not so thrilled by this analysis.
They are clearly trying to make out as though it only deserves a tiny fee so that if it ever goes to court over FRAND costs/terms that they can use this as one of their arguments.

[benwaggoner]

They are clearly trying to make out as though it only deserves a tiny fee so that if it ever goes to court over FRAND costs/terms that they can use this as one of their arguments.
Fair enough. And on further consideration, their analysis might apply well to the market of licensees, who cover a lot more use cases than premium streaming content.

[birdie]

No idea for whom this could be useful for: Tencent cloud now supports H.266 (https://intl.cloud.tencent.com/dynamic/news-details/100152).

[FranceBB]

No idea for whom this could be useful for: Tencent cloud now supports H.266 (https://intl.cloud.tencent.com/dynamic/news-details/100152).

The more the better.
I'd like to see more companies getting ready to adopt the standard as they'll put the pressure on hardware manufacturers into actually supporting the decoding.
Once we get there, it's done, ehehehehe
In the meantime, I'm still eagerly waiting for a public release of x266, but I guess we'll still have to play with the reference encoder for a bit longer... :(


Yeah. Bandwidth savings are just part of the value of newer codecs. Being able to improve quality of service to lower bandwidth customers is also huge. And helping customers watch more content under their capped/metered bandwidth is also important. There are also material costs to higher bitrates in content encoding, storage, and CDN cache consumption (lower bitrates means more minutes of content can be cached at the edge).

Yep, although, sadly, most of the times companies go into the money-saving direction as managers don't know anything about this world and the only thing they want is an immediate cost reduction on the CDN, so they use lower bitrates to achieve more or less the same subjective quality. At least, this was the direction I felt our manager was pushing towards back with H.265: data reduction, not quality improvement. On the other hand, lots of things have changed so maybe just maybe this time it's gonna be about quality improvement at the same bitrate. I'll let you know when we'll get there, however this is now handled by a different department called "Technology", so, whatever they're gonna do, I won't get a say on that. What I'll get a say on, though, is communication-wise for broadcast mezzanines. You see, nowadays we don't really send obi-vans (that fire up a beam to the satellite) for news any longer (unless we really need to) and the cameraman are sent there with backpacks that get the uncompressed FULL HD signal from the camera, encode it live in H.265 and transmit it via internet using 5G (or fallback to 4G, 3G, 2G if the network ain't available). This signal is then routed via a matrix to EVS and an hardware MPEG-2 encoder divides the 50p in fields and encodes it to XDCAM-50 (so MPEG-2 50 Mbit/s 25i). Of course, the live encode can't be that good 'cause it has to work within a relatively short time-frame and the delay can be from 1 second (generally 3 seconds on live events) up to 20 seconds if we're really short on bandwidth. We've seen some remarkable improvements going from H.264 to H.265 back then and I expect a similar improvement going from H.265 to H.266. If that's the case, it's gonna be a game changer for live news coverage around the globe.

[VictorLS]

New player video YUView for VVC
https://ient.github.io/YUView/
Can anybody play H.266 (VVC) with YUView (I can't play with it even more simple files in Win7x64 with YUView) or another players (I haven't tried i.e. VLC yet) test file TransportRecord11973-59130659.ts (94 MB) https://disk.yandex.ru/d/eQseiH5X73uZyQ I've recorded during test translation from 19e2 SAT more than year ago? If yes, how?

[quietvoid]

It probably has to be demuxed into a raw VVC bitstream to feed to YUView, which then uses vvcdec to decode it into YUV.
I'm not sure what software supports the demuxing part though.

[IHateCMDLine]

.....

[FranceBB]

Question number 1: Why is the Encoder using 01% of my 56c/112th Intel Xeon CPU and can we speed it up?

Question number 2: How can I get the same GOP size I would get with x262/x264/x265 when --ref 4 is set and nothing else is? Keyframes should be 24/250 by default, how can I get that here? I can't seem to get --IntraPeriod=1 --GOPSize=1 to work properly 'cause this way they're all intra, but as I change something, it complains about the GOP and it never works...


EncoderApp.exe --SummaryVerboseness --InputFile=test.yuv --BitstreamFile=video_2.vvc --SourceWidth=3840 --SourceHeight=2160 --FrameRate=30000/1001 --InputBitDepth=8 --OutputBitDepth=8 --MSBExtendedBitDepth=8 --InternalBitDepth=0 --InputChromaFormat=420 --TargetBitrate=25000 --IntraPeriod=1 --GOPSize=1 --Profile=auto --Level=5.1 --Tier=high --ChromaFormatIDC=420 --MatrixCoefficients=9 --InputColorPrimaries=1 --LMCSSignalType=2 --ConformanceWindowMode=1 --FramesToBeEncoded=6001 --HashME=1 --IBC=1 --DecodingRefreshType=1 --InputSampleRange=1 --AspectRatioInfoPresent=1 --ChromaLocInfoPresent=1 --MaxCUWidth=32 --MaxCUHeight=32 --CTUSize=64 --MaxBTLumaISlice=64 --MaxBTChromaISlice=64 --MaxBTNonISlice=64 --MaxTTLumaISlice=64 --MaxTTChromaISlice=64 --MaxTTNonISlice=64 --CostMode=lossy --BDPCM=0 --ColorTransform=0 --VideoFullRange=0 --ChromaTS=1 --DepQuant=1 --LMCSEnable=1 --RDOQ=1 --RDOQTS=1 --SBT=1 --ISP=1 --MTS=1 --MTSIntraMaxCand=4 --MTSInterMaxCand=4 --LFNST=1 --JointCbCr=1 --SAO=1 --TransformSkip=1 --TransformSkipFast=1 --TransformSkipLog2MaxSize=5 --SAOLcuBoundary=0 --ALF=1 --CCALF=1 --InputChromaFormat=422 --ChromaFormatIDC=422 --ColorTransform=1 --VideoFullRange=1 --ChromaTS=1 --DepQuant=0 --LMCSEnable=0 --RDOQ=0 --RDOQTS=0 --SBT=0 --ISP=0 --MTS=3 --LFNST=0 --JointCbCr=0 --VerCollocatedChroma=1 --SAO=0 --TransformSkip=1 --TransformSkipFast=1 --TransformSkipLog2MaxSize=5 --SAOLcuBoundary=0 --Log2MaxTbSize=5 --ALF=0 --CCALF=0 --BIO=0 --PROF=0 --SearchRange=64 --QpInValCb="17 22 34 42" --QpOutValCb="17 23 35 39" --BCW=0 --BcwFast=0 --BIO=0 --CIIP=0 --Geo=0 --AffineAmvr=0 --LMCSUpdateCtrl=1 --LMCSOffset=0 --DMVR=0 --SMVD=0 --PROF=0 --ISPFast=1 --FastMIP=1 --FastLFNST=1 --FastLocalDualTreeMode=0 --AffineAmvrEncOpt=0 --MmvdDisNum=8 --OnePictureOnlyConstraintFlag=0 --RateControl=0 --SEIDecodedPictureHash=1 --MaxLayers=1 --CbQpOffset=1 --CrQpOffset=1 --TemporalSubsampleRatio=1 --LCTUFast=1 --TemporalFilter=0 --DualITree=1 --MinQTLumaISlice=8 --MinQTChromaISliceInChromaSamples=4 --MinQTNonISlice=8 --MaxMTTHierarchyDepth=3 --MaxMTTHierarchyDepthISliceL=3 --MaxMTTHierarchyDepthISliceC=3 --MMVD=1 --Affine=1 --MaxNumMergeCand=6 --LMChroma=1 --IMV=1 --MRL=1 --IBC=0 --AllowDisFracMMVD=1 --MIP=1 --PBIntraFast=1 --FastMrg=1 --AMaxBT=1 --HadamardME=1 --FEN=1 --FDM=1

pause


So far it's been 6 minutes and it still hasn't encoded a single frame...
The performance is ridiculous and impossible to use on a daily basis.

[benwaggoner]

Question number 1: Why is the Encoder using 01% of my 56c/112th Intel Xeon CPU and can we speed it up?
Sounds like it is single-threaded. The encoder needs to be updated to support parallelism. x264/x265 demonstrate that a lot of parallelism is in encoders. VVC is based on those, so I expect equivalent maturity VVC encoders to support at least as much parallelism. Maybe more; x265 supports more than x264.

Question number 2: How can I get the same GOP size I would get with x262/x264/x265 when --ref 4 is set and nothing else is? Keyframes should be 24/250 by default, how can I get that here? I can't seem to get --IntraPeriod=1 --GOPSize=1 to work properly 'cause this way they're all intra, but as I change something, it complains about the GOP and it never works...
Ref shouldn't have any impact on GOP size. I'd check the documentation.

So far it's been 6 minutes and it still hasn't encoded a single frame...
The performance is ridiculous and impossible to use on a daily basis.
You're using the reference encoder? If so, those are used for developing the codec, and are never suitable for production use. A number of vendors are working on VVC encoders with real-world performance.

There is Fraunhofer's https://github.com/fraunhoferhhi/vvenc. It's explicitly meant to offer practical encoding times.

x266 is also in development, although there haven't been any public releases yet. https://multicorewareinc.com/x266-a-state-of-the-art-open-source-code-for-vvc-encoding-by-multicoreware-inc/

It generally takes a couple of years from the bitstream standard being complete before stable and reasonably good quality/perf general-use encoders become broadly available.

[Funky080900]

Question number 2: How can I get the same GOP size I would get with x262/x264/x265 when --ref 4 is set and nothing else is? Keyframes should be 24/250 by default, how can I get that here? I can't seem to get --IntraPeriod=1 --GOPSize=1 to work properly 'cause this way they're all intra, but as I change something, it complains about the GOP and it never works...

VTM doesn't support GOP size of 250 and neither does VVenC.
https://github.com/fraunhoferhhi/vvenc/issues/28

Question number 1: Why is the Encoder using 01% of my 56c/112th Intel Xeon CPU and can we speed it up?

VTM by default is single threaded and you have 112 threads, so that's ~1% utilization.
VVenC has presets and multithreading, so you probably want to use that one instead of VTM.

Example: vvencapp -s 3840x2160 -r 30 -c yuv420 --internal-bitdepth 8 --preset faster --threads 16 --qp 32 -ip 256 -o VVC.266 -i input.yuv

[Jamaika]

VTM doesn't support GOP size of 250 and neither does VVenC.
VTM has no frames IPB.
Try EVC
xeve_app.exe -i "113.yuv" -o "output_10bit.evc" -v 2 -d 8 -m 4 -b 15 -I 256 --input-csp 1 --codec-bit-depth 10 --rc-type 1 --bitrate 3Mbps -w 1280 -h 720 -z 29 --frames 1000 --preset medium --level-idc 6.3

[LigH]

Inverse Telecine is not a part of the encoding core features. It is rather pre-filtering.

[FranceBB]

Thanks for the replies.
Of course I know that reference encoders are what they are, but since we have heard nothing for months and months from multicoreware about x266 (aside for the fact that they're working on it and that they won't make it open source until the right time comes), I was looking for a short time replacement to make some comparisons, but apparently the reference encoder is single threaded and most importantly it's Intra only, with no IPB GOP possible, which makes it unusable.

@Jamaika... I'm gonna try with xeve_app.exe. Do you have a place where I can find the x64 Windows builds?

Inverse Telecine is not a part of the encoding core features. It is rather pre-filtering.

Yep, it's something that has to be done in a frameserver like Avisynth etc, but this actually leads me to an interesting question: is interlace gone for good in H.266, or is it still gonna be around just to piss Ben? XD

[quietvoid]

we have heard nothing for months and months from multicoreware about x266 (aside for the fact that they're working on it and that they won't make it open source until the right time comes)
There was this video but it's still months ago: https://www.youtube.com/watch?v=vFefmUUzv-c
Might be interesting to you. At least it's more recent than the announcement itself.

[nevcairiel]

is interlace gone for good in H.266, or is it still gonna be around

Seems like same level as support as HEVC, no specific interlace coding tools, but you can signal that a bitstream contains fields instead of frames - so you can encode interlaced that way.

[Jamaika]

Question number 1: Why is the Encoder using 01% of my 56c/112th Intel Xeon CPU and can we speed it up?
If you used my codec it didn't have SIMD options SSE41, SSE42, AVX, AVX2, AVX512(3). EncoderApp hasn't std::thread function. VTM is only 32bit. No matter if it compiles to x86_64
Are my codecs working properly with multithreading in Windows 10? I don't know, because I don't know what are worth upgrading to gcc 12 in the mingw-std-thread add-on.
https://github.com/Jamaika1/mingw_std_threads

EncoderApp.exe --SummaryVerboseness --InputFile=test.yuv --BitstreamFile=video_2.vvc --SourceWidth=3840 --SourceHeight=2160 --FrameRate=30000/1001 --InputBitDepth=8 --OutputBitDepth=8 --MSBExtendedBitDep =8 --InternalBitDepth=0 --InputChromaFormat=420 --TargetBitrate=25000 --IntraPeriod=1 --GOPSize=1 --Profile=auto --Level=5.1 --Tier=wysoka --ChromaFormatIDC=420 --MatrixCoefficients=9 --InputColorPrimaries=1 --LMCSSignalType=2 --ConformanceWindowMode=1 --FramesToBeEncoded=6001 --HashME=1 --IBC=1 --DecodingRefreshType= 1 --InputSampleRange=1 --AspectRatioInfoPresent=1 --ChromaLocInfoPresent=1 --MaxCUWidth=32 --MaxCUHeight=32 --CTUSize=64 --MaxBTLumaISlice=64 --MaxBTChromaISlice=64 --MaxBTNonISlice=64 --MaxTTLumaISlice= 64 --MaxTTChromaISlice=64 --MaxTTNonISlice=64 --CostMode=stratna --BDPCM=0 --ColorTransform=0 --VideoFullRange=0 --ChromaTS=1 --DepQuant=1 --LMCSEnable=1 --RDOQ= 1 --RDOQTS=1 --SBT=1 --ISP=1 --MTS=1 --MTSIntraMaxCand=4 --MTSInterMaxCand=4 --LFNST=1 --JointCbCr=1 --SAO=1 --TransformSkip= 1 --TransformSkipFast=1 --TransformSkipLog2MaxSize=5 --SAOLcuBoundary=0 --ALF=1 --CCALF=1 --InputChromaFormat=422 --ChromaFormatIDC=422 --ColorTransform=1 --VideoFullRange=1--ChromaTS=1 --DepQuant=0 --LMCSEnable=0 --RDOQ=0 --RDOQTS=0 --SBT=0 --ISP=0 --MTS=3 --LFNST=0 --JointCbCr=0 --VerCollocatedChroma=1 --SAO=0 --TransformSkip=1 --TransformSkipFast=1 --TransformSkipLog2MaxSize=5 --SAOLcuBoundary=0 --Log2MaxTbSize=5 --ALF=0 --CCALF=0 --BIO=0 --PROF=0 --ZakresWyszukiwania=64 --QpInValCb="17 22 34 42" --QpOutValCb="17 23 35 39"--BCW=0 --BcwFast=0 --BIO=0 --CIIP=0 --Geo=0 --AffineAmvr=0 --LMCSUpdateCtrl=1 --LMCSOffset=0 --DMVR=0 --SMVD=0 --PROF=0 --ISPFast=1 --FastMIP=1 --FastLFNST=1 --FastLocalDualTreeMode=0 --AffineAmvrEncOpt=0 --MmvdDisNum=8 --OnePictureOnlyConstraintFlag=0 --RateControl=0 --SEIDecodedPictureHash=1 --MaxLayers=1 --CbQpOffset=1 --CrQpOffset=1 --TemporalSubsampleRatio=1 --LCTUFast=1 --TemporalFilter=0 --DualITree=1 --MinQTLumaISlice=8 --MinQTChromaISliceInChromaSamples=4 --MinQTNonISlice=8 --MaxMTTHierarchyDepth=3 --MaxMTTHierarchyDepthISliceL=3 --MaxMTTHierarchyDepthISliceC=3 --MMVD=1 --Affine=1 --MaxNumMergeCand=6 --LMChroma=1 --IMV=1 --MRL=1 --IBC=0 --AllowDisFracMMVD=1 --MIP=1 --PBIntraFast=1 --FastMrg=1 --AMaxBT=1 --HadamardME=1 --FEN=1 --FDM=1--Affine=1 --MaxNumMergeCand=6 --LMChroma=1 --IMV=1 --MRL=1 --IBC=0 --AllowDisFracMMVD=1 --MIP=1 --PBIntraFast=1 --FastMrg=1 --AMaxBT=1 --HadamardME=1 --FEN=1 --FDM=1--Affine=1 --MaxNumMergeCand=6 --LMChroma=1 --IMV=1 --MRL=1 --IBC=0 --AllowDisFracMMVD=1 --MIP=1 --PBIntraFast=1 --FastMrg=1 --AMaxBT=1 --HadamardME=1 --FEN=1 --FDM=1
The given functions for encoder are for screenshot losses only. The latest VTM 13.2 codec doesn't work with lossless features. GOP is one. There are no B-frame config given.
# Type POC QPoffset QPOffsetModelOff QPOffsetModelScale CbQPoffset CrQPoffset QPfactor tcOffsetDiv2 betaOffsetDiv2 CbTcOffsetDiv2 CbBetaOffsetDiv2 CrTcOffsetDiv2 CrBetaOffsetDiv2 temporal_id #ref_pics_active_L0 #ref_pics_L0 reference_pictures_L0 #ref_pics_active_L1 #ref_pics_L1 reference_pictures_L1
Frame1: B 16 1 0.0 0.0 0 0 1.0 0 0 0 0 0 0 0 2 3 16 32 24 2 2 16 32
Frame2: B 8 1 -4.8848 0.2061 0 0 1.0 0 0 0 0 0 0 1 2 2 8 16 2 2 -8 8
Frame3: B 4 4 -5.7476 0.2286 0 0 1.0 0 0 0 0 0 0 2 2 2 4 12 2 2 -4 -12
Frame4: B 2 5 -5.90 0.2333 0 0 1.0 0 0 0 0 0 0 3 2 2 2 10 2 3 -2 -6 -14
Frame5: B 1 6 -7.1444 0.3 0 0 1.0 0 0 0 0 0 0 4 2 2 1 -1 2 4 -1 -3 -7 -15
Frame6: B 3 6 -7.1444 0.3 0 0 1.0 0 0 0 0 0 0 4 2 2 1 3 2 3 -1 -5 -13
Frame7: B 6 5 -5.90 0.2333 0 0 1.0 0 0 0 0 0 0 3 2 2 2 6 2 2 -2 -10
Frame8: B 5 6 -7.1444 0.3 0 0 1.0 0 0 0 0 0 0 4 2 2 1 5 2 3 -1 -3 -11
Frame9: B 7 6 -7.1444 0.3 0 0 1.0 0 0 0 0 0 0 4 2 3 1 3 7 2 2 -1 -9
Frame10: B 12 4 -5.7476 0.2286 0 0 1.0 0 0 0 0 0 0 2 2 2 4 12 2 2 -4 4
Frame11: B 10 5 -5.90 0.2333 0 0 1.0 0 0 0 0 0 0 3 2 2 2 10 2 2 -2 -6
Frame12: B 9 6 -7.1444 0.3 0 0 1.0 0 0 0 0 0 0 4 2 2 1 9 2 3 -1 -3 -7
Frame13: B 11 6 -7.1444 0.3 0 0 1.0 0 0 0 0 0 0 4 2 3 1 3 11 2 2 -1 -5
Frame14: B 14 5 -5.90 0.2333 0 0 1.0 0 0 0 0 0 0 3 2 3 2 6 14 2 2 -2 2
Frame15: B 13 6 -7.1444 0.3 0 0 1.0 0 0 0 0 0 0 4 2 3 1 5 13 2 2 -1 -3
Frame16: B 15 6 -7.1444 0.3 0 0 1.0 0 0 0 0 0 0 4 2 4 1 3 7 15 2 2 -1 1
The new x266 codec on github doesn't exist. What is invested in vvc?
Openvvc decoder. Everything would be OK, but I can't compile it.
https://github.com/OpenVVC/OpenVVC/tree/dev
Latest untested codecs in my garbage dump.
https://www.sendspace.com/file/4ukanc

[Funky080900]

the reference encoder is single threaded and most importantly it's Intra only
VTM isn't intra only. The only limitation is that the intraperiod (keyframe interval) has to be a multiple of the gopsize (16/32). Intraperiod of 240 is possible when gopsize=16. Since 250 isn't a multiple of 32 the closest possible intraperiod is 256. The same applies to VVenC currently.

[Jamaika]

VTM isn't intra only. The only limitation is that the intraperiod (keyframe interval) has to be a multiple of the gopsize (16/32). Intraperiod of 240 is possible when gopsize=16. Since 250 isn't a multiple of 32 the closest possible intraperiod is 256. The same applies to VVenC currently.
This is not true for today.
Parameter Check Error: GOP Size must be between 1 and 64
Parameter Check Error: GOP list auto config only supported GOP sizes: 1, 16, 32
cannot init the VVenC encoder
VVEncoderApp.exe [error]: cannot create encoder, error -2

[Jamaika]

Can VVC do 29.97 to 23.97 lower frame rate encoding?
If it is to be divisible by 1001 then you have to add it manually in the codec.
switch( vvencappCfg.m_FrameRate )
{
case 23: temporalRate = 24000; temporalScale = 1001; break;
case 29: temporalRate = 30000; temporalScale = 1001; break;
case 59: temporalRate = 60000; temporalScale = 1001; break;
default: break;
}

[Funky080900]

Well it does say that supported GOP sizes are 1, 16 and 32. GOP size 1 is probably for low delay and all intra. Just leave GOP size at default.
It appears that FranceBB had a problem because he set --IntraPeriod=1 --GOPSize=1. Try --IntraPeriod=256 --GOPSize=32 instead.

[Jamaika]

Test codecs:
VVEncoderApp.exe -i "113.yuv" -o "output_10bit.vvc" -v 5 -t 4 -s 1280x720 -r 29 -c yuv420 -g 32 -ip 256 --internal-bitdepth 10 --bitrate 3000000 --passes 1 -f 1000 --preset medium --level 6.3 --tier high
xeve_app.exe -i "113.yuv" -o "output_10abit.evc" -v 3 -d 8 -m 4 -w 1280 -h 720 -z 29 -b 15 -I 256 --input-csp 1 --codec-bit-depth 10 --rc-type 1 --bitrate 3Mbps --frames 1000 --preset medium --level-idc 6.3 --profile main
EncoderApp.exe --SummaryVerboseness -c "encoder_randomaccess_vtm.cfg" --InputFile=113.yuv --BitstreamFile=video_2.vvc --SourceWidth=1280 --SourceHeight=720 --FrameRate=29 --InputBitDepth=8 --InternalBitDepth=12 --OutputBitDepth=10 --MSBExtendedBitDepth=8 --InputChromaFormat=420 --ChromaFormatIDC=420 --ConformanceWindowMode=1 --FramesToBeEncoded=1000 --LMCSSignalType=0 --Level=6.3 --BDPCM=1 --Tier=high --IBC=1 --OverscanInfoPresent=1 --AspectRatioInfoPresent=1 --ChromaLocInfoPresent=1 --Log2MaxTbSize=5 --VerCollocatedChroma=1 --DecodingRefreshType=1

VVEncoderApp is now faster than xeve, but incompatible with newer EncoderApp.
Support for players is currently impossible because decoders don't have Y4M, i.e. they don't contain framerate, colormatrix, output bitdepth information.
Standard xeve baseline profile is fast but has much poorer quality at low bitrates.

[FranceBB]

Try --IntraPeriod=256 --GOPSize=32 instead.

Using IntraPeriod=256 and GOPSize=32 ends up with:

VVCSoftware: VTM Encoder Version 13.0rc1 [Windows][GCC 10.3.0][64 bit] [SIMD=AVX2]


Error: found fewer Reference Picture Sets than GOPSize
Error: Invalid GOP structure given


EncoderApp.exe --SummaryVerboseness --InputFile=test.yuv --BitstreamFile=video_2.vvc --SourceWidth=3840 --SourceHeight=2160 --FrameRate=30000/1001 --InputBitDepth=8 --OutputBitDepth=8 --MSBExtendedBitDepth=8 --InternalBitDepth=0 --InputChromaFormat=420 --TargetBitrate=25000 --IntraPeriod=256 --GOPSize=32 --Profile=auto --Level=5.1 --Tier=high --ChromaFormatIDC=420 --MatrixCoefficients=9 --InputColorPrimaries=1 --LMCSSignalType=2 --ConformanceWindowMode=1 --FramesToBeEncoded=6001 --HashME=1 --IBC=1 --DecodingRefreshType=1 --InputSampleRange=1 --AspectRatioInfoPresent=1 --ChromaLocInfoPresent=1 --MaxCUWidth=32 --MaxCUHeight=32 --CTUSize=64 --MaxBTLumaISlice=64 --MaxBTChromaISlice=64 --MaxBTNonISlice=64 --MaxTTLumaISlice=64 --MaxTTChromaISlice=64 --MaxTTNonISlice=64 --CostMode=lossy --BDPCM=0 --ColorTransform=0 --VideoFullRange=0 --ChromaTS=1 --DepQuant=1 --LMCSEnable=1 --RDOQ=1 --RDOQTS=1 --SBT=1 --ISP=1 --MTS=1 --MTSIntraMaxCand=4 --MTSInterMaxCand=4 --LFNST=1 --JointCbCr=1 --SAO=1 --TransformSkip=1 --TransformSkipFast=1 --TransformSkipLog2MaxSize=5 --SAOLcuBoundary=0 --ALF=1 --CCALF=1 --InputChromaFormat=422 --ChromaFormatIDC=422 --ColorTransform=1 --VideoFullRange=1 --ChromaTS=1 --DepQuant=0 --LMCSEnable=0 --RDOQ=0 --RDOQTS=0 --SBT=0 --ISP=0 --MTS=3 --LFNST=0 --JointCbCr=0 --VerCollocatedChroma=1 --SAO=0 --TransformSkip=1 --TransformSkipFast=1 --TransformSkipLog2MaxSize=5 --SAOLcuBoundary=0 --Log2MaxTbSize=5 --ALF=0 --CCALF=0 --BIO=0 --PROF=0 --SearchRange=64 --QpInValCb="17 22 34 42" --QpOutValCb="17 23 35 39" --BCW=0 --BcwFast=0 --BIO=0 --CIIP=0 --Geo=0 --AffineAmvr=0 --LMCSUpdateCtrl=1 --LMCSOffset=0 --DMVR=0 --SMVD=0 --PROF=0 --ISPFast=1 --FastMIP=1 --FastLFNST=1 --FastLocalDualTreeMode=0 --AffineAmvrEncOpt=0 --MmvdDisNum=8 --OnePictureOnlyConstraintFlag=0 --RateControl=0 --SEIDecodedPictureHash=1 --MaxLayers=1 --CbQpOffset=1 --CrQpOffset=1 --TemporalSubsampleRatio=1 --LCTUFast=1 --TemporalFilter=0 --DualITree=1 --MinQTLumaISlice=8 --MinQTChromaISliceInChromaSamples=4 --MinQTNonISlice=8 --MaxMTTHierarchyDepth=3 --MaxMTTHierarchyDepthISliceL=3 --MaxMTTHierarchyDepthISliceC=3 --MMVD=1 --Affine=1 --MaxNumMergeCand=6 --LMChroma=1 --IMV=1 --MRL=1 --IBC=0 --AllowDisFracMMVD=1 --MIP=1 --PBIntraFast=1 --FastMrg=1 --AMaxBT=1 --HadamardME=1 --FEN=1 --FDM=1

pause





I wanna try xeve. Does anyone have a Windows Build?


By the way, setting it back to --IntraPeriod=1 --GOPSize=1 works, but as I said it's unusable as it's single thread:

https://i.imgur.com/DR6SbsA.png

https://i.imgur.com/YsRiwiF.png

And leaving aside the other things I'm doing with Avisynth spawned across my farm, it's using just 1 core:

https://i.imgur.com/jsaXqiB.png



EDIT 1: 10 minutes passed and not a single UHD H.266 VVC frame has been produced yet.
EDIT 2: 20 minutes passed and not a single UHD H.266 VVC frame has been produced yet.
EDIT 3: 1h and 20 minutes passed and just 2 frames out of 6001 have been encoded in H.266 VVC... As I said, it's unusable...

https://i.imgur.com/dtKfbxg.png

[Funky080900]

EncoderApp.exe --SummaryVerboseness --InputFile=test.yuv --BitstreamFile=video_2.vvc --SourceWidth=3840 --SourceHeight=2160 --FrameRate=30000/1001 --InputBitDepth=8 --OutputBitDepth=8 --MSBExtendedBitDepth=8 --InternalBitDepth=0 --InputChromaFormat=420 --TargetBitrate=25000 --IntraPeriod=256 --GOPSize=32 --Profile=auto --Level=5.1 --Tier=high --ChromaFormatIDC=420 --MatrixCoefficients=9 --InputColorPrimaries=1 --LMCSSignalType=2 --ConformanceWindowMode=1 --FramesToBeEncoded=6001 --HashME=1 --IBC=1 --DecodingRefreshType=1 --InputSampleRange=1 --AspectRatioInfoPresent=1 --ChromaLocInfoPresent=1 --MaxCUWidth=32 --MaxCUHeight=32 --CTUSize=64 --MaxBTLumaISlice=64 --MaxBTChromaISlice=64 --MaxBTNonISlice=64 --MaxTTLumaISlice=64 --MaxTTChromaISlice=64 --MaxTTNonISlice=64 --CostMode=lossy --BDPCM=0 --ColorTransform=0 --VideoFullRange=0 --ChromaTS=1 --DepQuant=1 --LMCSEnable=1 --RDOQ=1 --RDOQTS=1 --SBT=1 --ISP=1 --MTS=1 --MTSIntraMaxCand=4 --MTSInterMaxCand=4 --LFNST=1 --JointCbCr=1 --SAO=1 --TransformSkip=1 --TransformSkipFast=1 --TransformSkipLog2MaxSize=5 --SAOLcuBoundary=0 --ALF=1 --CCALF=1 --InputChromaFormat=422 --ChromaFormatIDC=422 --ColorTransform=1 --VideoFullRange=1 --ChromaTS=1 --DepQuant=0 --LMCSEnable=0 --RDOQ=0 --RDOQTS=0 --SBT=0 --ISP=0 --MTS=3 --LFNST=0 --JointCbCr=0 --VerCollocatedChroma=1 --SAO=0 --TransformSkip=1 --TransformSkipFast=1 --TransformSkipLog2MaxSize=5 --SAOLcuBoundary=0 --Log2MaxTbSize=5 --ALF=0 --CCALF=0 --BIO=0 --PROF=0 --SearchRange=64 --QpInValCb="17 22 34 42" --QpOutValCb="17 23 35 39" --BCW=0 --BcwFast=0 --BIO=0 --CIIP=0 --Geo=0 --AffineAmvr=0 --LMCSUpdateCtrl=1 --LMCSOffset=0 --DMVR=0 --SMVD=0 --PROF=0 --ISPFast=1 --FastMIP=1 --FastLFNST=1 --FastLocalDualTreeMode=0 --AffineAmvrEncOpt=0 --MmvdDisNum=8 --OnePictureOnlyConstraintFlag=0 --RateControl=0 --SEIDecodedPictureHash=1 --MaxLayers=1 --CbQpOffset=1 --CrQpOffset=1 --TemporalSubsampleRatio=1 --LCTUFast=1 --TemporalFilter=0 --DualITree=1 --MinQTLumaISlice=8 --MinQTChromaISliceInChromaSamples=4 --MinQTNonISlice=8 --MaxMTTHierarchyDepth=3 --MaxMTTHierarchyDepthISliceL=3 --MaxMTTHierarchyDepthISliceC=3 --MMVD=1 --Affine=1 --MaxNumMergeCand=6 --LMChroma=1 --IMV=1 --MRL=1 --IBC=0 --AllowDisFracMMVD=1 --MIP=1 --PBIntraFast=1 --FastMrg=1 --AMaxBT=1 --HadamardME=1 --FEN=1 --FDM=1

pause

Is there a reason why you don't use a configuration file? You might have given the encoder an invalid configuration. There's a configuration file supplied with VTM.
https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/-/blob/master/cfg/encoder_randomaccess_vtm.cfg


VVCSoftware: VTM Encoder Version 13.0rc1 [Windows][GCC 10.3.0][64 bit] [SIMD=AVX2]


Error: found fewer Reference Picture Sets than GOPSize
Error: Invalid GOP structure given

Using encoder_randomaccess_vtm.cfg should solve the problem.

I just encoded with the newest version:

EncoderAppStatic -c encoder_randomaccess_vtm.cfg -wdt 640 -hgt 360 -fr 24 --InputBitDepth=8 -f 25 -q 32 -ip 256 -b zzz.266 -i in.yuv

VVCSoftware: VTM Encoder Version 13.2 [Linux][GCC 10.3.0][64 bit] [SIMD=AVX2]

TOOL CFG: IBD:1 HAD:1 RDQ:1 RDQTS:1 RDpenalty:0 LQP:0 SQP:0 ASR:1 MinSearchWindow:96 RestrictMESampling:0 FEN:1 ECU:0 FDM:1 ESD:0 TransformSkip:1 TransformSkipFast:1 TransformSkipLog2MaxSize:5 ChromaTS:1 BDPCM:0 Tiles: 1x1 Slices: 1 MCTS:0 SAO:1 ALF:1 CCALF:1 WPP:0 WPB:0 PME:2 WaveFrontSynchro:0 WaveFrontSubstreams:1 ScalingList:0 TMVPMode:1 DQ:1 SignBitHidingFlag:0 RecalQP:0
TOOL CFG: LFNST:1 MMVD:1 Affine:1 AffineType:1 PROF:1 SbTMVP:1 DualITree:1 IMV:1 BIO:1 LMChroma:1 HorCollocatedChroma:1 VerCollocatedChroma:0 MTS: 1(intra) 0(inter) SBT:1 ISP:1 SMVD:1 CompositeLTReference:0 Bcw:1 BcwFast:1 LADF:0 CIIP:1 Geo:1 AllowDisFracMMVD:1 AffineAmvr:1 AffineAmvrEncOpt:1 DMVR:1 MmvdDisNum:6 JointCbCr:1 ACT:0 PLT:0 IBC:0 HashME:0 WrapAround:0 VirtualBoundariesEnabledFlag:0 VirtualBoundariesPresentInSPSFlag:1 vertical virtual boundaries:[ ] horizontal virtual boundaries:[ ] Reshape:1 (Signal:SDR Opt:0 CSoffset:6) MRL:1 MIP:1 EncDbOpt:0
FAST TOOL CFG: LCTUFast:1 FastMrg:1 PBIntraFast:1 IMV4PelFast:1 MTSMaxCand: 4(intra) 4(inter) ISPFast:0 FastLFNST:0 AMaxBT:1 E0023FastEnc:1 ContentBasedFastQtbt:0 UseNonLinearAlfLuma:1 UseNonLinearAlfChroma:1 MaxNumAlfAlternativesChroma:8 FastMIP:0 FastLocalDualTree:1 RPR:0 TemporalFilter:1 SEI CTI:0


started @ Mon Aug 2 14:50:38 2021
POC 0 LId: 0 TId: 0 ( IDR_N_LP, I-SLICE, QP 29 ) 39344 bits [Y 37.4395 dB U 45.2781 dB V 47.2091 dB] [ET 32 ] [L0] [L1]
POC 16 LId: 0 TId: 1 ( STSA, B-SLICE, QP 34 ) 4808 bits [Y 36.9225 dB U 44.1890 dB V 47.0744 dB] [ET 40 ] [L0 0] [L1 0c]
POC 8 LId: 0 TId: 2 ( STSA, B-SLICE, QP 35 ) 944 bits [Y 37.0796 dB U 44.7483 dB V 47.1147 dB] [ET 15 ] [L0 0 16] [L1 16c 0]
POC 4 LId: 0 TId: 3 ( STSA, B-SLICE, QP 38 ) 336 bits [Y 37.1753 dB U 44.9897 dB V 47.2049 dB] [ET 7 ] [L0 0 8] [L1 8c 16]
POC 2 LId: 0 TId: 4 ( STSA, B-SLICE, QP 40 ) 200 bits [Y 37.2324 dB U 45.0539 dB V 47.2280 dB] [ET 6 ] [L0 0 4] [L1 4c 8]
POC 1 LId: 0 TId: 5 ( STSA, B-SLICE, QP 41 ) 176 bits [Y 37.2328 dB U 45.0660 dB V 47.2289 dB] [ET 4 ] [L0 0 2] [L1 2c 4]
POC 3 LId: 0 TId: 5 ( STSA, B-SLICE, QP 41 ) 176 bits [Y 37.1449 dB U 45.0543 dB V 47.2142 dB] [ET 4 ] [L0 2c 0] [L1 4 8]
POC 6 LId: 0 TId: 4 ( STSA, B-SLICE, QP 40 ) 176 bits [Y 37.0388 dB U 44.7476 dB V 47.1829 dB] [ET 7 ] [L0 4c 0] [L1 8 16]
POC 5 LId: 0 TId: 5 ( STSA, B-SLICE, QP 41 ) 176 bits [Y 37.0651 dB U 44.8193 dB V 47.1670 dB] [ET 5 ] [L0 4 0] [L1 6c 8]
POC 7 LId: 0 TId: 5 ( STSA, B-SLICE, QP 41 ) 168 bits [Y 37.0317 dB U 44.7668 dB V 47.1612 dB] [ET 5 ] [L0 6c 4] [L1 8 16]
POC 12 LId: 0 TId: 3 ( STSA, B-SLICE, QP 38 ) 392 bits [Y 36.8999 dB U 44.4305 dB V 47.1487 dB] [ET 8 ] [L0 8c 0] [L1 16 8]
POC 10 LId: 0 TId: 4 ( STSA, B-SLICE, QP 40 ) 192 bits [Y 36.9165 dB U 44.5405 dB V 47.1531 dB] [ET 6 ] [L0 8 0] [L1 12c 16]
POC 9 LId: 0 TId: 5 ( STSA, B-SLICE, QP 41 ) 184 bits [Y 36.9741 dB U 44.5939 dB V 47.1667 dB] [ET 5 ] [L0 8 0] [L1 10c 12]
POC 11 LId: 0 TId: 5 ( STSA, B-SLICE, QP 41 ) 176 bits [Y 36.8766 dB U 44.5556 dB V 47.1199 dB] [ET 5 ] [L0 10c 8] [L1 12 16]
POC 14 LId: 0 TId: 4 ( STSA, B-SLICE, QP 40 ) 248 bits [Y 36.8815 dB U 44.0459 dB V 47.0970 dB] [ET 7 ] [L0 12c 8] [L1 16 12]
POC 13 LId: 0 TId: 5 ( STSA, B-SLICE, QP 41 ) 208 bits [Y 36.8243 dB U 44.1208 dB V 47.1059 dB] [ET 5 ] [L0 12 8] [L1 14c 16]
POC 15 LId: 0 TId: 5 ( STSA, B-SLICE, QP 41 ) 200 bits [Y 36.8165 dB U 44.1494 dB V 47.0991 dB] [ET 4 ] [L0 14c 12] [L1 16 14]
POC 24 LId: 0 TId: 2 ( STSA, B-SLICE, QP 35 ) 2680 bits [Y 36.7076 dB U 43.4063 dB V 46.8300 dB] [ET 29 ] [L0 16 0] [L1 16c 0]
POC 20 LId: 0 TId: 3 ( STSA, B-SLICE, QP 38 ) 328 bits [Y 36.7980 dB U 43.8611 dB V 46.9917 dB] [ET 7 ] [L0 16 0] [L1 24c 16]
POC 18 LId: 0 TId: 4 ( STSA, B-SLICE, QP 40 ) 184 bits [Y 36.8152 dB U 43.9075 dB V 47.0298 dB] [ET 6 ] [L0 16 0] [L1 20c 24]
POC 17 LId: 0 TId: 5 ( STSA, B-SLICE, QP 41 ) 184 bits [Y 36.8413 dB U 44.0156 dB V 47.0344 dB] [ET 5 ] [L0 16 0] [L1 18c 20]
POC 19 LId: 0 TId: 5 ( STSA, B-SLICE, QP 41 ) 168 bits [Y 36.7934 dB U 43.8192 dB V 46.9912 dB] [ET 5 ] [L0 18c 16] [L1 20 24]
POC 22 LId: 0 TId: 4 ( STSA, B-SLICE, QP 40 ) 208 bits [Y 36.7459 dB U 43.6633 dB V 46.8977 dB] [ET 6 ] [L0 20c 16] [L1 24 20]
POC 21 LId: 0 TId: 5 ( STSA, B-SLICE, QP 41 ) 176 bits [Y 36.7549 dB U 43.7819 dB V 46.9210 dB] [ET 5 ] [L0 20 16] [L1 22c 24]
POC 23 LId: 0 TId: 5 ( STSA, B-SLICE, QP 41 ) 184 bits [Y 36.6674 dB U 43.4940 dB V 46.8775 dB] [ET 5 ] [L0 22c 20] [L1 24 22]

LayerId 0
Total Frames | Bitrate Y-PSNR U-PSNR V-PSNR YUV-PSNR
25 a 50.1274 36.9470 44.3639 47.0900 38.4110

finished @ Mon Aug 2 14:54:43 2021
Total Time: 245.085 sec. [user] 245.141 sec. [elapsed]


But if you want a multithreaded VVC encoder that is easier to configure, use VVenC instead.

[FranceBB]

Is there a reason why you don't use a configuration file?



There's a very simple answer to this question: I didn't know I needed one xD



There's a configuration file supplied with VTM.
https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/-/blob/master/cfg/encoder_randomaccess_vtm.cfg


Using encoder_randomaccess_vtm.cfg should solve the problem.


OK, test in progress.

It's working with:

EncoderApp.exe -c "encoder_randomaccess_vtm.cfg" -wdt 3840 -hgt 2160 -fr 24000/1001 -f 6001 --InputBitDepth=8 --TargetBitrate=25000 -i test.yuv -b video.vvc

however it's still slow as hell...


But if you want a multithreaded VVC encoder that is easier to configure, use VVenC instead.

Yeah, I'm gonna try with VVEnc, but I really need a Windows Build, otherwise I'll try to build it myself...

I mean, I could make tests by encoding an SD file in H.266, but... is it really worth comparing SD files? I mean, c'mon... it's a codec that targets 8K, we can't make SD comparisons...

[benwaggoner]

I mean, I could make tests by encoding an SD file in H.266, but... is it really worth comparing SD files? I mean, c'mon... it's a codec that targets 8K, we can't make SD comparisons...
AV1 has also been marketed as needed for 8K, but it's not like there were many 8K test streams when the bitstream and encoders were being developed.

A good codec will be good across the bitrate spectrum. VVC might show a larger differential advantage over HEVC at 8K, but it should have a big one at SD and below. One key improvement is that its motion estimation shouldn't leave blocky artifacts at low bitrates like older codecs, and that matters most at low bitrates and resolutions.

[birdie]

The standard was finalized almost a year ago, yet we have no content, no fast encoders and zero software decoders (aside from very rare hardware solutions which have been just demoed so far with no actual products hitting retail/esale). That all sounds weird. Maybe it's always been like that.

[LigH]

@FranceBB: Not so huge inline images, please. Rather linked thumbs where possible.

[FranceBB]

@FranceBB: Not so huge inline images, please. Rather linked thumbs where possible.

My fault, fixed. ;)

[ksec]

The standard was finalized almost a year ago, yet we have no content, no fast encoders and zero software decoders (aside from very rare hardware solutions which have been just demoed so far with no actual products hitting retail/esale). That all sounds weird. Maybe it's always been like that.

Pretty much all previous MPEG codec has always been like that. While VVC was standardised in August 2020, VTM testing and conformance was still being developed in October with some further enhancement in December if I remember correctly.

As a matter of fact nearly all codec works like that. It takes at least two to three years to get everything up and running. And that is assuming everyone works together on it. Which anyone working in any sort of business will know isn't always going to be the case.

[birdie]

Thanks!

From: https://www.mpegstandards.org/135th-meeting-of-mpeg/

Verification tests for more application cases of Versatile Video Coding (VVC)
The third round of verification testing for VVC (ISO/IEC 23090-3 and Rec. ITU-T H.266) has been completed. This includes the testing of High Dynamic Range (HDR) content of 4K ultra-high-definition (UHD) resolution using the Hybrid Log-Gamma (HLG) and Perceptual Quantization (PQ) video formats. The test was conducted using state-of-the-art high-quality consumer displays, emulating an internet streaming-type scenario.

On average, VVC showed on average approximately 50% bit rate reduction compared to the previous major generation of MPEG video coding standard known as High Efficiency Video Coding (HEVC), published in 2013.

[MythCreator]

Just a win build of VVenc, still extremely slow though
VVenc-1.1.0-vs2019 (https://megaupload.hosting/users/zhuyu1987/13845/VVenc-1.1.0-vs2019)

[vpupkind]

The standard was finalized almost a year ago, yet we have no content, no fast encoders and zero software decoders (aside from very rare hardware solutions which have been just demoed so far with no actual products hitting retail/esale). That all sounds weird. Maybe it's always been like that.

Doesn't VLC already decode VVC?
Here is a VVC paper from Ateme (commercial encoder vendor) who seem to be using it and GPAC: https://arxiv.org/abs/2106.14245

[birdie]

Doesn't VLC already decode VVC?
Here is a VVC paper from Ateme (commercial encoder vendor) who seem to be using it and GPAC: https://arxiv.org/abs/2106.14245

It does but if ffmpeg doesn't support it, nothing that I use, does.

The patch to support it was last pushed (https://ffmpeg.org/pipermail/ffmpeg-devel/2021-March/277385.html) in March 2021 but it hasn't been merged.

[nevcairiel]

The patch to support it was last pushed (https://ffmpeg.org/pipermail/ffmpeg-devel/2021-March/277385.html) in March 2021 but it hasn't been merged.

That patch does not have a decoder.

[birdie]

That patch does not have a decoder.

The decoder patch was queued even earlier and also hasn't been merged.

[Dann0245]

My R5 3600 cpu with vvenc 1.1.0 could get around 3 fps at preset Fast, vvenc can't use all 100% cpu, max 75% and below.

It is anime content, res 1920 x 1080

quality surprises me at low bitrate when compare to HEVC preset Slower, which I usually use.

and 3 fps is faster than HEVC Slower, I only get below 2.5 fps at this preset.

https://2.pik.vn/2021147259ea-1689-4ec3-b54a-83e05d319d7a.jpg

But decode side is painful

https://2.pik.vn/20214334a2ef-6530-40d3-b40d-73a32fce4b47.jpg

[FranceBB]

Just a win build of VVenc, still extremely slow though
VVenc-1.1.0-vs2019 (https://megaupload.hosting/users/zhuyu1987/13845/VVenc-1.1.0-vs2019)

Where? Your link leads me to an empty folder.
Are you sure you made it public?

https://i.imgur.com/vr7z0rP.png
https://i.imgur.com/num0kpD.png

Doesn't VLC already decode VVC?


Ah, really? That's good to know.

ffmpeg doesn't support it

That's a shame, really, as ffmpeg is used as a decoder by many programs and it's the base of our beloved Avisynth indexers and also MPV which is my de facto player of choice.


My R5 3600 cpu with vvenc 1.1.0 could get around 3 fps at preset Fast, vvenc can't use all 100% cpu, max 75% and below.

It is anime content, res 1920 x 1080

That's nice, 3fps for FULL HD is acceptable and I think I can use it to finally have a proper test with my UHD Masterfile.
I'll let you know how it goes as soon as I get my hands on a Windows build (if @MythCreator replies)

[Dann0245]

@FranceBB

My Windows build.

https://drive.google.com/drive/folders/1ZanLlQXG9K06uKpYWlzDYYlvCrMwQohg?usp=sharing


I build from

vvenc: https://github.com/fraunhoferhhi/vvenc

vvdec: https://github.com/fraunhoferhhi/vvdec

[FranceBB]

@FranceBB

My Windows build.

https://drive.google.com/drive/folders/1ZanLlQXG9K06uKpYWlzDYYlvCrMwQohg?usp=sharing


Thanks, mate! ;)
It's working just fine! :D

ffmpeg.exe -i "AVS Script.avs" -strict -1 -an -f yuv4mpegpipe - | vvencapp.exe -i - --preset medium --format yuv420 --bitrate 25000 --profile auto --level 5.0 --hdr pq --passes 1 --output "VVC.h266"

pause

https://i.imgur.com/vrS99D9.png

and it's also pretty fast in UHD :D

https://i.imgur.com/aDLOPWD.png
https://i.imgur.com/DsgPU7H.png

[benwaggoner]

What kind of fps did you get?

[ksec]

Thanks, mate! ;)
It's working just fine! :D



https://i.imgur.com/vrS99D9.png

and it's also pretty fast in UHD :D

https://i.imgur.com/aDLOPWD.png
https://i.imgur.com/DsgPU7H.png

Ok the last pic is just showing off :D

[Funky080900]

ffmpeg.exe -i "AVS Script.avs" -strict -1 -an -f yuv4mpegpipe - | vvencapp.exe -i - --preset medium --format yuv420 --bitrate 25000 --profile auto --level 5.0 --hdr pq --passes 1 --output "VVC.h266"

pause
In VVenC bitrate is specified in bits per second rather than kilobits/second. So 25000 is just 25 kbps which is probably not what you wanted.

[FranceBB]

In VVenC bitrate is specified in bits per second rather than kilobits/second. So 25000 is just 25 kbps which is probably not what you wanted.

Dammit, I figured it out when I saw the final file being as little as 14 MB and I was like: WUT?!
Now I'm gonna try again with 25000000 bits per second which should be 25000 kbits/s so 25 Mbit/s and after that I'll show you some nice SSIM/PSNR stats. :)

Ok the last pic is just showing off :D

Eheheheh you got me xD

What kind of fps did you get?

It doesn't say in the cmd, but it was definitely much faster than VTM as VVEnc took around 1h to encode 6000 frames in UHD, so with a very basic calculation we have 6000 FPH, 100 FPM and around 2 FPS. Taking into account the 1 Gbit/s network slowdown (the source was a 1.5 Gbit/s 12bit 4:4:4 Apple ProRes), the fact that Avisynth indexers like ffms2 are not particularly optimized for it and the pipe of the pipe (Avisynth -> FFMpeg -> VVEnc) that's surprisingly fast for a reference encoder which is not using all the cores.

[Gravitator]

in vvenc bitrate is specified in bits per second rather than kilobits/second. So 25000 is just 25 kbps which is probably not what you wanted.
I got caught too! :D
--bitrate, --kbitrate, --mbitrate ;)

[MythCreator]

Where? Your link leads me to an empty folder.
Are you sure you made it public?

https://i.imgur.com/vr7z0rP.png
https://i.imgur.com/num0kpD.png



Ah, really? That's good to know.



That's a shame, really, as ffmpeg is used as a decoder by many programs and it's the base of our beloved Avisynth indexers and also MPV which is my de facto player of choice.




That's nice, 3fps for FULL HD is acceptable and I think I can use it to finally have a proper test with my UHD Masterfile.
I'll let you know how it goes as soon as I get my hands on a Windows build (if @MythCreator replies)

It's public now, sorry for the inconvenient...

And as to the extremely slow, I think maybe it's something with my script?
vspipe "test.vpy" - | vvencapp.exe -s 1920x1080 --framerate 23.976 -f 500 --threads 16 --preset slower -q 18 -i - --output "test.vvc"

I dithered bit depth to 10 in vpy, the ET for only 1 frame is around 500.

[Gravitator]

It's public now, sorry for the inconvenient...
Share the decoder?

[MythCreator]

Share the decoder?

Done.

[FranceBB]

as to the extremely slow, I think maybe it's something with my script?
vspipe "test.vpy" - | vvencapp.exe -s 1920x1080 --framerate 23.976 -f 500 --threads 16 --preset slower -q 18 -i - --output "test.vvc"

I dithered bit depth to 10 in vpy, the ET for only 1 frame is around 500.

I don't know, it shouldn't make any difference if your pipe comes from VapourSynth and mine from Avisynth, however with me getting around 2 FPS for UHD, I expected you to get more than 3FPS for FULL HD. Still, 2fps is something I can live with as it's dramatically faster than VTM. About the dithering, I have been dithering down the input as well in Avisynth using the Floyd Steinberg error diffusion. Anyway, next week, when I'm gonna have the server free from whatever my coworkers here at Sky are encoding, I'm gonna re-encode a few masterfiles in H.266, H.265, H.264 and MPEG-2 at the same bitrate, namely 25 Mbit/s and see how they behave.

[Gravitator]

Done.
Thanks!
------
Who has a thought about the reason for the violation of the exit from me?
Enc:
C:\>ffmpeg -i z:/space_6s.mkv -pix_fmt yuv420p -frames 1 -f yuv4mpegpipe - | vvencapp.exe -s 1920x1080 --framerate 23.976 --threads 2 --preset medium -q 30 -i - --output z:\test.vvc
Dec_1:
C:\>vvdecapp.exe -b z:\test.vvc -o z:\exit.yuv

Dec_2
C:\>ffmpeg -video_size 1920x1080 -framerate 23976/1001 -pix_fmt yuv420p10le -i z:\exit.yuv z:\output.jpeg
https://i.ibb.co/gvS46RG/output.jpg (https://ibb.co/HNthXH0)

The problem is solved through the second feeding method:
C:\>ffmpeg -i z:/space_6s.mkv -pix_fmt yuv420p -frames 1 -f rawvideo - | vvencapp.exe -s 1920x1080 --framerate 23.976 --threads 2 --preset medium -q 30 -i - --output z:\test2.vvc
https://i.ibb.co/yQ3dkz0/output2.jpg (https://ibb.co/0Gwm90q)

[MythCreator]

I don't know, it shouldn't make any difference if your pipe comes from VapourSynth and mine from Avisynth, however with me getting around 2 FPS for UHD, I expected you to get more than 3FPS for FULL HD. Still, 2fps is something I can live with as it's dramatically faster than VTM. About the dithering, I have been dithering down the input as well in Avisynth using the Floyd Steinberg error diffusion. Anyway, next week, when I'm gonna have the server free from whatever my coworkers here at Sky are encoding, I'm gonna re-encode a few masterfiles in H.266, H.265, H.264 and MPEG-2 at the same bitrate, namely 25 Mbit/s and see how they behave.

I figured it out lol. --preset slower shouldn't be named as slower, placebo is more accurate. --preset fast is 100 times faster than Slower at least.

[FranceBB]

--preset slower shouldn't be named as slower, placebo is more accurate.

LOL
It's a good thing that I generally stick with --preset medium then ehehehehehe

[Gravitator]

C:\>ffmpeg -i z:/space_6s.mkv -pix_fmt yuv420p -f rawvideo - | vvencapp.exe -s 1920x1080 --framerate 23.976 --rskip 0 --threads 2 --preset medium -q 30 -i - --output z:\VVC_R0.vvc
I get this:
command line error: Unknown option `rskip' (value:`0')
How to disable --rskip?

[LigH]

Please do not assume that vvencapp supports all the same parameters as x265. You won't find an rskip parameter mentioned in vvencapp --fullhelp

[Gravitator]

Please do not assume that vvencapp supports all the same parameters as x265. You won't find an rskip parameter mentioned in vvencapp --fullhelp
Terribly scarce settings :angry:
Let's wait for advanced modification of ... ;)

[Funky080900]

There is the “full-featured” version of VVenC which has more settings. Don't know about rskip tho.

[Gravitator]

There is the “full-featured” version of VVenC which has more settings.
Where is it?

[Funky080900]

You should get both vvencapp (https://github.com/fraunhoferhhi/vvenc#how-to-use-the-standard-encoder) and vvencFFapp (https://github.com/fraunhoferhhi/vvenc#how-to-use-the-full-featured-expert-mode-encoder) when following the build instructions (https://github.com/fraunhoferhhi/vvenc#how-to-build-vvenc).

[LigH]

They still depend on Visual Studio. Or are Jamaika's patches (https://forum.doom9.org/showthread.php?p=1930419#post1930419) still sufficient for compilation with GCC (maybe in MABS)?

[Gravitator]

A new VVC ecoder at the AV1 level (visually gives 25% better quality than x265).

[birdie]

A new VVC ecoder at the AV1 level (visually gives 25% better quality than x265).

Is this a question or a statement? If the latter it's very much debatable because from what I've seen VVC is much much better than AV1 while being a lot less computationally expensive. In terms of compression efficiency only AV2 targets VVC but then again at the expense of being more CPU hungry.

I'm curious MulticoreWare has pretty much ceased x265 development (there have been very few commits for the past half a year), yet x266 is nowhere to be seen. Ha! Their x266 GIT repo (https://bitbucket.org/multicoreware/x266/src/master/) does exist but it's for authorized users only.

[Gravitator]

Is this a question or a statement? If the latter it's very much debatable because from what I've seen VVC is much much better than AV1 while being a lot less computationally expensive. In terms of compression efficiency only AV2 targets VVC but then again at the expense of being more CPU hungry.
This is a statement on my test.
I expect that disabling --rskip should give VVC: medium a victory over x265: placebo.

[Gravitator]

You can download > Test_VVC_AV1_x265 (https://files.videohelp.com/u/227452/Test_VVC_AV1_x265.rar)
AV1 gives clearer textures on dark areas (lines and ship skin).
VVC:
-s 1920x1080 --framerate 23.976 --preset slower -q 29
AV1:
--cpu-used=0 --target-bitrate=1000 --max-partition-size=64 --sb-size=64 --input-bit-depth=10 --bit-depth=10
x265:
--output-depth 10 --profile main10 --qg-size 64 --opt-cu-delta-qp --tu-intra-depth 4 --tu-inter-depth 4 --hme --hme-search star,star,star --subme 4 --rect --amp --max-merge 2 --no-early-skip --rskip 0 --tskip --opt-ref-list-length-pps --bframes 6 --ref 4 --rc-lookahead 150 --bitrate 1100 --crf-min 0.00 --crf-max 0.00 --qpfile GENERATED_QP_FILE --limit-refs 0 --rd 5 --psy-rd 1.00 --rdoq-level 1 --psy-rdoq 10.00 --aq-strength 2 --sao-non-deblock --limit-sao --psnr --range limited --colormatrix bt709

[benwaggoner]

Is this a question or a statement? If the latter it's very much debatable because from what I've seen VVC is much much better than AV1 while being a lot less computationally expensive.
Do you mean a lot less computationally expensive for encode or decode?

[birdie]

Do you mean a lot less computationally expensive for encode or decode?

Both.

[birdie]

AV1 gives clearer textures on dark areas (lines and ship skin).


x265 has seen many years of refinements and improvements. x266 hasn't even been released yet. We are talking about proof of concept encoders.

Also, I've no idea how to play VVC.vvc. Please just upload PNGs to imgsli or something.

[Gravitator]

Also, I've no idea how to play VVC.vvc.
A temporary solution...
Convert to Ut Video/lossless video format:
vvdecapp.exe -b c:\VVC.vvc -o c:\VVC.yuv && ffmpeg -video_size 1920x1080 -framerate 23976/1001 -pix_fmt yuv420p10le -i c:\VVC.yuv -c:v -acodec -vcodec utvideo -color_primaries 1 -color_trc 1 -colorspace 1 с:\VVC.mkv && del c:\VVC.yuv
Play it via FFplay:
vvdecapp.exe -b с:\VVC.vvc -o - | ffplay -f rawvideo -s 1920x1080 -pix_fmt yuv420p10le -

FFplay hot key control:

- q / ESC - exit
- f - full screen mode
- f / Space - pause
- m - on / off sound
- 9 / / - volume -
- 0 / * - volume +
- s - frame by frame
Rewind:
- left / right arrows - rewind 10 seconds
- up / down arrows - rewind 1 second
- Page up / Page down - rewind to the previous / next part or by 10 minutes

[Jamaika]

x265 has seen many years of refinements and improvements. x266 hasn't even been released yet. We are talking about proof of concept encoders.

Also, I've no idea how to play VVC.vvc. Please just upload PNGs to imgsli or something.
For amateurs. VVC codec isn't created for converting bt709 PNG images to 10/12bit bt2020 fullrange images. Despite the HDR image, there is no desire to develop HDR for JPEG2000 or HEIF. JPEG XS is to have new possibilities, but no one has seen it. The new JPEG and VVC codecs are to have much greater data protection in the fight against piracy. Yes, not every file we open. Is VVC photo codec? Not. Can raw images from Canon apertures be converted to VVC. I failed. Converting CR2 to TIFF Adobe RGB is already lossy. In theory, it is possible. When we have converter suitable for yuv files and VVC codec with HDRtools functions. FFmpeg doesn't convert raw camera files to yuv bt2020. Problem with how to convert photos to yuv and then play back on TV. After all, TVs today hasn't VVC decoder and home monitors are 8bit bt709.

ffmpeg.exe -loglevel error -i 111.png -an -f rawvideo -frames 1 -vf scale=1280:720:in_color_matrix=bt709:in_range=full:out_color_matrix=bt709:out_range=full,format=yuv420p 111.yuv

EncoderApp.exe --SummaryVerboseness --InputFile=111.yuv --BitstreamFile=image.vvc --SourceWidth=1563 --SourceHeight=1558 --FrameRate=25.000 --InputBitDepth=8 --OutputBitDepth=10 --MSBExtendedBitDepth=8 --MatrixCoefficients=0 --InputColorPrimaries=-1 --LMCSSignalType=2 --ConformanceWindowMode=1 --FramesToBeEncoded=1 --HashME=1 --IBC=1 --DecodingRefreshType=1 --Profile=auto --InputSampleRange=1 --AspectRatioInfoPresent=1 --ChromaLocInfoPresent=1 --MaxCUWidth=16 --MaxCUHeight=16 --CTUSize=32 --MaxBTLumaISlice=32 --MaxBTChromaISlice=32 --MaxBTNonISlice=32 --MaxTTLumaISlice=32 --MaxTTChromaISlice=32 --MaxTTNonISlice=32 --CostMode=lossless --InputChromaFormat=444 --ChromaFormatIDC=444 --QP=0 --BDPCM=1 --ColorTransform=1 --VideoFullRange=1 --ChromaTS=1 --DepQuant=0 --LMCSEnable=0 --RDOQ=0 --RDOQTS=0 --SBT=0 --ISP=0 --MTS=0 --LFNST=0 --JointCbCr=0 --LoopFilterDisable=1 --SAO=0 --TransformSkip=1 --TransformSkipFast=1 --TransformSkipLog2MaxSize=5 --SAOLcuBoundary=0 --Log2MaxTbSize=5 --ALF=0 --CCALF=0 --BIO=0 --PROF=0 --InternalBitDepth=0 --IntraPeriod=1 --GOPSize=1 --SearchRange=64 --QpInValCb="17 22 34 42" --QpOutValCb="17 23 35 39" --BCW=0 --BcwFast=0 --BIO=0 --CIIP=0 --Geo=0 --AffineAmvr=0 --LMCSUpdateCtrl=1 --LMCSOffset=0 --DMVR=0 --SMVD=0 --PROF=0 --ISPFast=1 --FastMIP=1 --FastLFNST=1 --FastLocalDualTreeMode=0 --AffineAmvrEncOpt=0 --MmvdDisNum=8 --OnePictureOnlyConstraintFlag=1 --GciPresentFlag=1 --Level=15.5 --Tier=high --RateControl=0 --SubpicDecodedPictureHash=1 --MaxLayers=1 --CbQpOffset=1 --CrQpOffset=1 --TemporalSubsampleRatio=1 --LCTUFast=1 --TemporalFilter=0 --DualITree=1 --MinQTLumaISlice=8 --MinQTChromaISliceInChromaSamples=4 --MinQTNonISlice=8 --MaxMTTHierarchyDepth=3 --MaxMTTHierarchyDepthISliceL=3 --MaxMTTHierarchyDepthISliceC=3 --MMVD=1 --Affine=1 --SbTMVP=1 --MaxNumMergeCand=6 --LMChroma=1 --IMV=1 --MRL=1 --IBC=0 --AllowDisFracMMVD=1 --MIP=1 --PBIntraFast=1 --FastMrg=1 --AMaxBT=1 --HadamardME=1 --FEN=1 --FDM=1 --VerCollocatedChroma=1

[birdie]

For amateurs.

:eek::eek::eek:

I was talking about converting VVC to PNG which must be a lossless conversion :)

[Jamaika]

And here's the problem. Fraunhofer VVC Encoder isn't lossless. Is HDRtools enough for the image? Who knows that.

[birdie]

And here's the problem. Fraunhofer VVC Encoder isn't lossless. Is HDRtools enough for the image? Who knows that.

I was talking about a lossy encode by Gravitator which would be easier for everyone to check without using console. Could you calm down a bit? :cool:

[Jamaika]

Lossy coding. Fraunhofer VVC only has basic functions. For me it is codec advertisement and an attempt to catch up with the competition. The codec is lagging behind in development.
Why is it free. I do not know. It is not the only company with vvc technology.
VVC has nothing to compare with x265 presets. The first HEVC Mainconcept codecs were also underdeveloped and the quality compared with x265 was deliberately poor. Whoever made movies in Sony Vegas at low bitrates knows what it looked like.
It changed when there was youtube.
Today Fraunhofer HEVC/VVC is trying to do something with these features and that's not just a challenge. It will take time to fine tune the presets and fix the bugs. In addition, it is trying to convert the codec from c++11 to c++20 with new features, which will also take some time.

[benwaggoner]

:eek::eek::eek:

I was talking about converting VVC to PNG which must be a lossless conversion :)
PNG is natively a full range RGB format. So you still have a color space and range conversion in the process. Normally it's fine going from 8-bit YUV to 8-bit RGB, with the inverse much more lossy. But it's still not lossless.

[benwaggoner]

Lossy coding. Fraunhofer VVC only has basic functions. For me it is codec advertisement and an attempt to catch up with the competition. The codec is lagging behind in development.
Why is it free. I do not know. It is not the only company with vvc technology.
VVC has nothing to compare with x265 presets. The first HEVC Mainconcept codecs were also underdeveloped and the quality compared with x265 was deliberately poor. Whoever made movies in Sony Vegas at low bitrates knows what it looked like.
It changed when there was youtube.
Today Fraunhofer HEVC/VVC is trying to do something with these features and that's not just a challenge. It will take time to fine tune the presets and fix the bugs. In addition, it is trying to convert the codec from c++11 to c++20 with new features, which will also take some time.
It's quite normal for a variety of companies to offer their own encoder implementations in the early stage of a codec's market introduction. They've needed to build their own for internal testing, and might as well share them to promote market acceptance.

[birdie]

PNG is natively a full range RGB format. So you still have a color space and range conversion in the process. Normally it's fine going from 8-bit YUV to 8-bit RGB, with the inverse much more lossy. But it's still not lossless.

Slight changes in the color palette are barely perceivable however the loss of detail is what people will notice right away, so comparing codecs after converting their results to PNG is still valid. Besides, codecs work with the same color space which means converting them to PNG will affect them equally.

[hajj_3]

VTM 14.0 is out.

[Gravitator]

The reason for the encoder's refusal to assign an I-frame for frame №60 (scene change) ?
Themselves encode and check.

VVenC v1.1.0/VVdeC v1.1.2:
ffmpeg -i c:/raw_1080p30.mkv -pix_fmt yuv420p -f rawvideo - | vvencapp.exe -s 1920x1080 --framerate 30 --threads 2 --preset medium -q 30 -i - --output c:\test.vvc && vvdecapp.exe -b c:\test.vvc -o c:\VVC.yuv && ffmpeg -video_size 1920x1080 -framerate 30 -pix_fmt yuv420p10le -i c:\vvc.yuv -c:v -acodec -vcodec utvideo -color_primaries 1 -color_trc 1 -colorspace 1 c:\final.mkv && del c:\vvc.yuv
Download source video file (305.6MB) > raw_1080p30.mkv (https://files.videohelp.com/u/227452/raw_1080p30.mkv)
https://i.ibb.co/x5bjJkh/I-59f.jpg (https://ibb.co/kcT8Q7K)

[Balling]

Haha, wow. https://thenextweb.com/news/h266-vvc-video-codec-streaming-standards

First H.266 streamer.

[Balling]

The reason for the encoder's refusal to assign an I-frame for frame №59 (scene change) ?
Themselves encode and check.



Not all I frames are key frames. /Facepalm

[Gravitator]

Not all I frames are key frames. /Facepalm
I corrected it to the number 60. What's the difference? The encoder did not catch the change - it did not allocate the necessary bitrate. It turned out correctly on x265.

[Funky080900]

What do you mean VVenC did not allocate necessary bitrate? You encoded with constant QP (-q 30). If you want to use rate control, specify a bitrate E.g. -b 1000000. And there's no scene change detection in VVenC currently, so keyframes get placed in regular intervals.

[rwill]

Damn, guys...

I just remembered some test of VP3 where someone compared VP3 to DivX 3.11 and he set the keyframe period to 9999 sec or frames, can't remember, in VP3 and then continued to complain about quality and seek times. Now DivX 3.11 was (hacked?) to place keyframes on scenecuts but VP3 just did what it was told. Didnt serve it well to take user input literally.

@Gravitator: Would you complain about broadcast too ? Because most broadcast encoders do not insert I frames on scene change as well. They rather run with a large fixed open gop because they do not care about the screen content.

[Gravitator]

What do you mean VVenC did not allocate necessary bitrate? You encoded with constant QP (-q 30).
Cropping did not reveal the problem in -q 30:
ffmpeg -ss 00:00:02 -t 00:00:06 -i c:/raw_1080p30.mkv -pix_fmt yuv420p -f rawvideo - | vvencapp.exe -s 1920x1080 --framerate 30 --threads 2 --preset medium -q 30 -i - --output c:\test.vvc && vvdecapp.exe -b c:\test.vvc -o c:\VVC.yuv && ffmpeg -video_size 1920x1080 -framerate 30 -pix_fmt yuv420p10le -i c:\vvc.yuv -c:v -acodec -vcodec utvideo -color_primaries 1 -color_trc 1 -colorspace 1 c:\final.mkv && del c:\vvc.yuv
The problem is --rskip (artifacts to the left of the tree).
And there's no scene change detection in VVenC currently, so keyframes get placed in regular intervals.
That's the news!:o

[ksec]

How the H.266 video standard will help stream content way faster

https://thenextweb.com/news/h266-vvc-video-codec-streaming-standards


While MX Player prefers to stream its content on H.266, depending on the device and network conditions, it might have to fall back to other standards such as AV1 or H.265 on some devices, until playback support for the new standard is baked into chips that are used in those gadgets. Other streaming players will also face this challenge and have to follow suit for a while.

Mantri said that the company has been servicing content through H.266 standard to almost 20% of its customer base and it has received no complaints.


MXplayer in India are already serving 20% of their content with H.266?

Just Wow. It seems they uses Tencent software decoding [1] [2] within their Apps. And the paper [3] did a test and despite it is still early version 0.01, an Apple A12 used in iPhone XR and XS managed to decode with 30fps. Not sure anyone wants to do that due to battery issues but nevertheless it works.

Interesting.

[1] https://github.com/TencentCloud/O266player

[2] https://multimedia.tencent.com/news/202102011

[3] https://arxiv.org/pdf/2103.03612.pdf

[excellentswordfight]

Damn, guys...

I just remembered some test of VP3 where someone compared VP3 to DivX 3.11 and he set the keyframe period to 9999 sec or frames, can't remember, in VP3 and then continued to complain about quality and seek times. Now DivX 3.11 was (hacked?) to place keyframes on scenecuts but VP3 just did what it was told. Didnt serve it well to take user input literally.

@Gravitator: Would you complain about broadcast too ? Because most broadcast encoders do not insert I frames on scene change as well. They rather run with a large fixed open gop because they do not care about the screen content.
Large? Most broacasters I've come across uses a short interval (good for channel switching) DVB recommendations for AVC/HEVC is to have an RAP interval of 2s... Closed GOPs are rather common as well. But yes, its rather common to use fixed GOP without scene cut detection.

[birdie]

Speaking of MX Player: it only allows to stream VVC files, it won't play local VVC files.

[benwaggoner]

I corrected it to the number 60. What's the difference? The encoder did not catch the change - it did not allocate the necessary bitrate. It turned out correctly on x265.
Reference encoders may not do dynamic IDR detection by default. Lots of evaluation processes are done with fixed GOP durations.

[rwill]

Large? Most broacasters I've come across uses a short interval (good for channel switching) DVB recommendations for AVC/HEVC is to have an RAP interval of 2s... Closed GOPs are rather common as well. But yes, its rather common to use fixed GOP without scene cut detection.

Ye, I meant large hierarchical GOPs, with like 4 or 5 hierarchies. Something like 15 or 31 B-Pictures. So a RAP interval of 32 or 64 depending on framerate.

[FranceBB]

Large? Most broacasters I've come across uses a short interval (good for channel switching) DVB recommendations for AVC/HEVC is to have an RAP interval of 2s... Closed GOPs are rather common as well. But yes, its rather common to use fixed GOP without scene cut detection.

Yep and with keyframe = framerate generally, so every second you're able to get one.
Switching across channels would be a pain otherwise, so you're right. ;)

Speaking of MX Player: it only allows to stream VVC files, it won't play local VVC files.

Ah... I see...

[benwaggoner]

Ye, I meant large hierarchical GOPs, with like 4 or 5 hierarchies. Something like 15 or 31 B-Pictures. So a RAP interval of 32 or 64 depending on framerate.
Yeah, some professional live encoders do some amazingly complex b-frame reference layering.

Obviously one can't have more B-frames than frames in the GOP, but these can get pretty complex even in 25 or 30 frames.

Are any live encoders using RADL yet? Those should be helpful for fixed GOP durations.

[rwill]

Yeah, some professional live encoders do some amazingly complex b-frame reference layering.

Obviously one can't have more B-frames than frames in the GOP, but these can get pretty complex even in 25 or 30 frames.

Are any live encoders using RADL yet? Those should be helpful for fixed GOP durations.

I think live encoders go with RASL/CRA to avoid the slight quality "flash" you get with RADL. RADL is more for bitstream splicing. I have not seen many streams from live encoders though so I don't know really.

[contemporarymind]

I think live encoders go with RASL/CRA to avoid the slight quality "flash" you get with RADL. RADL is more for bitstream splicing. I have not seen many streams from live encoders though so I don't know really.

RADL considerably affect overall coding efficiency compared to RASL depending on GOP size and intra period. Now that VVC allows for reference picture resampling, you can do bitstream splicing/http streaming also with RASL pics. check https://arxiv.org/pdf/2103.06675

[ksec]

RADL considerably affect overall coding efficiency compared to RASL depending on GOP size and intra period. Now that VVC allows for reference picture resampling, you can do bitstream splicing/http streaming also with RASL pics. check https://arxiv.org/pdf/2103.06675

VVC continues to surprise me.

[LigH]

So welcome on board, contemporarymind https://cosgan.de/images/smilie/froehlich/a010.gif

[benwaggoner]

VVC continues to surprised me.
Yeah, takes years before all the interesting nooks and crannies of a new codec get understood, and how the different parts interact with different kinds of content and use cases.

There's still stuff that HEVC that I seen thoroughly explored and optimized, like adaptive SAO parameters.

[FranceBB]

Avisynth Script:

ColorBars(1920, 1080, pixel_type="YV12")

ChangeFPS(23.976)

trim(0, 100)


VVEnc:


ffmpeg.exe -i "AVS Script.avs" -strict -1 -an -f yuv4mpegpipe - | vvencapp.exe -i - --preset medium --format yuv420 --bitrate 250000 --profile auto --level 5.0 --passes 1 --output "VVC.h266"

pause


VVDec:


vvdecapp.exe -b "VVC.h266" -o "VVC.yuv"

ffmpeg.exe -video_size 1920x1080 -framerate 24 -pix_fmt yuv420p -i "VVC.yuv" -c:v ffvhuff -color_primaries 1 -color_trc 1 -colorspace 1 -y "final.mkv"

pause



Final decoded result:

https://i.imgur.com/XYCpmAr.png


So it looks as if somewhere it gets converted and it's no longer yuv420p 8bit.
What happened?

[Gravitator]

So it looks as if somewhere it gets converted and it's no longer yuv420p 8bit.
What happened?
Dec YUV > -pix_fmt yuv420p10le

[Funky080900]

So it looks as if somewhere it gets converted and it's no longer yuv420p 8bit.
What happened?

VVenC wants raw yuv not y4m. Also, you should tell VVenC the frame rate (-r 24), especially when you use rate control. VVenC defaults to 60 fps, so unless you tell VVenC the frame rate, 250 kbps specified would give you ~ 100 kbps for a 24 fps input (250kbps/60×24=100kbps).

ffmpeg -i "AVS Script.avs" -pix_fmt yuv420p -f rawvideo - | vvencapp -s 1920x1080 -r 24 -c yuv420 --internal-bitdepth 8 --preset medium -b 250000 -p 1 -rs 10 -o VVC.266 -i -

vvdecapp -b VVC.266 -o - | ffmpeg -s:v 1920:1080 -framerate 24 -pixel_format yuv420p -f rawvideo -thread_queue_size 64 -i - -c ffvhuff -color_primaries 1 -color_trc 1 -colorspace 1 final.mkv -y

[benwaggoner]

A curse upon all video tools that support .yuv without supporting .y4m!

[rwill]

A curse upon all video tools that support .yuv without supporting .y4m!

I like .yuv more and .y4m is somewhat dated. I dont know if it even supports more than 8 bit officially.

With .yuv you can cut out a snippet very precisely just by skipping and copying blocks of bytes with a fixed size. Like with the Unix tool 'dd'. Cant do that with .y4m. And what does one save by using .y4m ? No need to specify size and fps ?

[birdie]

A paper on H.266 > H.265:

https://arxiv.org/pdf/2109.06555.pdf

[Balling]

"So it looks as if somewhere it gets converted and it's no longer yuv420p 8bit."

This is nv21 or nv12, i.e. semi-planar
ffplay.exe -video_size 1920x1080 -framerate 24 -pix_fmt nv21 -i file

You can also try yuv420p10 and p010le!


"y4m is somewhat dated"

Heh, we just updated it to support more stuff, i.e. ffmpeg color range extension!

See https://code.videolan.org/videolan/x264/-/merge_requests/69/diffs

[ksec]

A paper on H.266 > H.265:

https://arxiv.org/pdf/2109.06555.pdf

In addition, we demonstrated that the participants had noted a difference between uncompressed 4K and 8K at a viewing distance of 0.8H for most of the tested sequences.

0.8H is approximtely 0.8m, for an 85" TV

[Jamaika]

So it looks as if somewhere it gets converted and it's no longer yuv420p 8bit.
What happened?
https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/-/merge_requests/2119/diffs

[benwaggoner]

0.8H is approximately 0.8m, for an 85" TV
80mm from a 219mm screen? My geometry is pretty rusty, but wouldn't that would put the viewing angle to the edges of the screen at quite a bit more than >45 degrees! Not a comfortable or plausible viewing distance for entertainment content as it exists.

Maybe one could shoot with lots of surround to fill the peripheral vision, and used a curved screen or something...

[benwaggoner]

I like .yuv more and .y4m is somewhat dated. I dont know if it even supports more than 8 bit officially.
I certainly have plenty of 10-bit .y4m files that work perfectly with a variety of tools. And avoid the myriad issues of messing up some little parameter for input and getting a garbage encode. Height, width, chroma subsampling, bit depth, fps, there's a lot of different variables that aren't always documented.

With .yuv you can cut out a snippet very precisely just by skipping and copying blocks of bytes with a fixed size. Like with the Unix tool 'dd'. Cant do that with .y4m. And what does one save by using .y4m ? No need to specify size and fps ?
Well, with .y4m one could figure out where to cut frames like that without having to specify all the stream parameters. I think you'd just need an offset from the header.

[FranceBB]

During this comparison I've been encoding a 3840x2160 23.976fps progressive 4:2:0 yv12 8bit planar masterfile lossleslly captured from a 90s film: Goodfellas. The target encode bitrate has been CBR 25 Mbit/s with the very same GOP for all codecs.

MPEG-1 (https://i.imgur.com/jKCAyef.png) - MPEG-2 (https://i.imgur.com/NmIPHJw.png) - XVID (https://i.imgur.com/STfIWR4.png) - H.264 (https://i.imgur.com/3M8hHop.jpg) - H.265 (https://i.imgur.com/rViChT4.jpg) - H.266 (https://i.imgur.com/RSeraMH.jpg)

SSIM result in a 200 frames scene picked as a reference:

https://i.imgur.com/kdKRvrC.png

https://i.imgur.com/f0wW8Tz.png

https://i.imgur.com/csh5yCO.png

If we're gonna analyze H.265 and H.266 only, we're gonna have:

https://i.imgur.com/VlVDJpk.png

Aside from some particular frames, the overall H.266 score is greater than the H.265 one, so it has a better fidelity in terms of image representation compared to H.265. On the other hand, the difference between the two is shortened by the fact that x265 has been around for quite some time, while VVEnc for H.266 is still very fresh, very new, but despite this the score obtained by H.266 is higher. If we're gonna include H.264 in the graph, we're gonna get:

https://i.imgur.com/h5WX9w9.png

As we can clearly see from the image, H.264 gets much closer to H.265 than it gets to H.266, in fact in some frames H.264 gets an even higher score than H.265 as it prefers edge preservation and grain retention (which could create some artifacts at the edges of the transform blocks) compared to H.265 which prefers a cleaner yet more blurry image. Anyway, in general, H.265 is still performing better than H.264 and it gets a better overall score. Going towards inferior and older codecs like XVID, the difference with a new codec capable to handle high resolutions like H.266 widens:

https://i.imgur.com/b7unMbf.png

XVID, at the same bitrate as H.266, achieves way lower scores in almost every scene, but on the other hand it wasn't meant to handle resolutions as high as UHD and with bitrates as low as 25 Mbit/s.

https://i.imgur.com/NmVOEN3.png

Same goes for MPEG-2 which doesn't seem to be able to keep the pace of H.266 and this point is just as valid for MPEG-1.

https://i.imgur.com/MfIcQM1.png

Therefore with the new coding tools implemented in H.266, despite the increase in the computational cost, it's possible to achieve better performances in terms of compression compared to older codecs (or, seen in another light, it's possible to achieve an higher quality at the same size) and this difference gets wider and wider as we move towards older codecs.

If you're looking for the tables, I can share them as well.

Cheers,
Frank

[rwill]

If you're looking for the tables, I can share them as well.


I am looking for the encoders used with exact version, their configuration and the source file.

[FranceBB]

I am looking for the encoders used with exact version, their configuration and the source file.

I'll post those once I get back to the computer, but from my mobile I can tell you that I used BBMpeg1 v1.4, FFMpeg MPEG-2 ('cause x262 doesn't allow any frame size larger than FULL HD), xvid 1.3.7, x264 r3065, x265 3.5+16-7955046, VVEnc 1.1.0.

The source file is analogue as I stated.
Since I don't have any real lossless masterfiles from cameras (the best I can do is UHD in LogC HDR at 1 Gbit/s in Apple ProRes 12bit), I decided to use the lossless v210 UHD capture through a black magic decklink card connected via SDI of a 90s film stored safely in a humidity and temperature controlled environment 2 floors downstairs protected from any light source. I resized the chroma inside Avisynth and I dithered down with the Floyd Steinberg error diffusion to 8bit yv12 before feeding each encoder. The source was supposed to be interesting because it's really losslessly captured and because it's supposed to have lots of grain which is supposed to be preserved.

Side note: one of the main reasons why x264 and x265 performed so good (on top of having being around for such a long time) is the --tune ssim.
On top of that, I feel like VVEnc has still a long way to go, but the principles work in the sense that it is performing better than an H.265 encode via x265, even if by a tiny fraction.

[VoodooFX]

MPEG-1 (https://i.imgur.com/jKCAyef.png) - MPEG-2 (https://i.imgur.com/NmIPHJw.png) - XVID (https://i.imgur.com/STfIWR4.png) - H.264 (https://i.imgur.com/3M8hHop.jpg) - H.265 (https://i.imgur.com/rViChT4.jpg) - H.266 (https://i.imgur.com/RSeraMH.jpg)


That XviD screenshot is quite unfortunate. ;)

[FranceBB]

That XviD screenshot is quite unfortunate. ;)

Yep. Overall it's not so bad on the I frames, but that one looked bad and far worse than other ones.
They were all encoded with single pass, so I think the lookahead of xvid somehow screwed up there xD

[Jamaika]

A piece of good work but for me this test isn't very troublesome for the competition. How does AV1 vs VVC vs EVC compare?
Google codecs are updated all the time. VVC appears to be finished.

[birdie]

VVC is not dead yet, Apple is hiring new codec engineers (https://www.linkedin.com/jobs/view/video-codec-algorithm-engineer-at-apple-2743151392).

Expert knowledge in video and image coding principles, algorithms, and techniques

Expert knowledge and experience in video compression standards, such as H.264, HEVC, VVC, VP9, AV1

Experienced in assessing visual quality using both objective metrics and subjective techniques

Excellent software design and debugging skills and solid programming skills in C/C++

Good written and oral communication skills

Familiarity with video processing algorithms such as scaling, noise reduction, tone mapping, etc would be a plus

Familiarity with the latest computer vision and deep learning technologies would be a plus

[birdie]

Oh, here's probably the first 8K content (https://8kassociation.com/industry-info/newsletter/globo-makes-8k-olympics-content-available-vod/) to be offered in VVC.

[FranceBB]

VVenC wants raw yuv not y4m.

If anyone wants y4m to be implemented, please comment and/or upvote this issue: https://github.com/fraunhoferhhi/vvenc/issues/65

[VoodooFX]

I'll post those once I get back to the computer.
Nice, I'm waiting for that source sample.

[FranceBB]

Nice, I'm waiting for that source sample.

The question is: where can I upload it? 'cause 200 frames in v416 from the capture card is over 12 GB. I've re-encoded to FFV1 lossless and now it's around 2GB which means it's gonna be enough to be uploaded on We Transfer.
There we go: https://we.tl/t-WTV68YjuzS

Disclaimer: this sample comes from a losslessly captured film and is meant to be used for academic purposes only like codec testing by engineers in this particular instance, every other use or share across the internet is strictly prohibited and punishable.

The link will expire in 7 days.


H.266 VVC encode in .h266 (there's also a decoded and re-encoded to HuffYUV lossless muxed in .mkv version for those poor souls who can't decode H.266 files directly): https://we.tl/t-gC5K1IGsJj

[VoodooFX]

The question is: where can I upload it? 'cause 200 frames in v416 from the capture card is over 12 GB.
I dunno much about it but few times I was sent huge masters through this site - www.myairbridge.com

[FranceBB]

I dunno much about it but few times I was sent huge masters through this site - www.myairbridge.com

Generally we use Aspera but that's for one side to another, i.e one company to another or one individual to another only. Nonetheless FFV1 is lossless anyway, so it's fine I guess.

[LigH]

WeTransfer may work, or MediaFire.

[birdie]

https://mega.nz/ is great as well. Doesn't have access to your files as they are encrypted before uploading using your key.

[VoodooFX]

Nonetheless FFV1 is lossless anyway, so it's fine I guess.
It's fine. I did few tests with XviD, that first frame looks much better - my 1pass XviD (https://images2.imgbox.com/0d/e3/nK4gakB7_o.png) vs your XviD (https://i.imgur.com/STfIWR4.png). What matrix did you use?
Here is whole file to check (CQM used: EQM v3HR): https://we.tl/t-p0TbcabcDb

EDIT:
What did you use to show that SSIM info on the frame?

[benwaggoner]

Great stuff @FranceBB!

HEVC and VVC are both approaching the SSIM saturation point, and it might be interested to redo the AVC/HEVC/VVC comparison at perhaps 10 Mbps CBR.

The greater variability of SSIM between VVC frames is also interesting. VVC has some impressive motion artifact suppression technologies that might score a lot better psychovisually than SSIM (which is fundamentally designed for still image comparisons, not video). Does the oscillation correlates with B-frames or something? Is it visible in full-speed playback?

[FranceBB]

Great stuff @FranceBB!

HEVC and VVC are both approaching the SSIM saturation point, and it might be interested to redo the AVC/HEVC/VVC comparison at perhaps 10 Mbps CBR.

Yep, re-doing the test at a much lower bitrate is what I also wanna do 'cause it will definitely highlight more things. The 25 Mbit/s were picked 'cause our current UHD playout live H.265 hardware encoder is using 25 Mbit/s for every content, so I wanted the test to be as realistic as possible.


Does the oscillation correlates with B-frames or something? Is it visible in full-speed playback?

What I've noticed is relatively interesting. So basically we all know that any encoder is gonna assign more bits to the I than it will to the P and B, however if we compare it with the H.265 stream, we can see that x265 is spreading those a bit more evenly than VVEnc is for H.266. Let me be more specific: basically, since the final encode is gonna be CBR, I can see how "large" each frame is gonna be in the GOP and what I've noticed is that in H.265 we have like: Intra large, P and B a bit smaller, while in H.266 we have like: Intra very large, P and B much smaller to have the same bitrate in the end in both encodes, which means that either VVEnc better detected the blocks and macroblocks across the scene and was able to use motion compensation in a better way OR it's using some of the new psychovisual features so that it "thinks" that it doesn't need as much bitrate, but it actually does. What I can say, though, is that in motion, if you look closely, you can see the difference as you look at the grain pattern in the back which appears to be blurrier than other frames in the exact same points in which the SSIM score drops, so it looks like something didn't go as expected, but from my experience I feel like this has something to do with the VVEnc implementation rather than H.266 itself. I'm pretty sure that we're gonna see the bitrate much more evenly spread (and much closer to how it's spread in x265) in x266 when it will become available.

[Jamaika]

Yep, re-doing the test at a much lower bitrate is what I also wanna do 'cause it will definitely highlight more things. The 25 Mbit/s were picked 'cause our current UHD playout live H.265 hardware encoder is using 25 Mbit/s for every content, so I wanted the test to be as realistic as possible.

What I've noticed is relatively interesting. So basically we all know that any encoder is gonna assign more bits to the I than it will to the P and B, however if we compare it with the H.265 stream, we can see that x265 is spreading those a bit more evenly than VVEnc is for H.266. Let me be more specific: basically, since the final encode is gonna be CBR, I can see how "large" each frame is gonna be in the GOP and what I've noticed is that in H.265 we have like: Intra large, P and B a bit smaller, while in H.266 we have like: Intra very large, P and B much smaller to have the same bitrate in the end in both encodes, which means that either VVEnc better detected the blocks and macroblocks across the scene and was able to use motion compensation in a better way OR it's using some of the new psychovisual features so that it "thinks" that it doesn't need as much bitrate, but it actually does. What I can say, though, is that in motion, if you look closely, you can see the difference as you look at the grain pattern in the back which appears to be blurrier than other frames in the exact same points in which the SSIM score drops, so it looks like something didn't go as expected, but from my experience I feel like this has something to do with the VVEnc implementation rather than H.266 itself. I'm pretty sure that we're gonna see the bitrate much more evenly spread (and much closer to how it's spread in x265) in x266 when it will become available.
I failed to produce ABR for 10Mbps. Wrong data in VVC come out. I found bitrate low. As a curiosity I added CBR QP 24 for yuv420p10le bt2020 VVC and EVC placebo. The obtained result for codecs with similar codec technology. EVC has twice bitrate in I/P/B frames. This would mean either artificially inflating the result to better advertise the EVC codec or bugs in the VVC codec. Unfortunately for 4K 10Mbps there is lot of grayscale pixel averaging.
https://i.ibb.co/0FTs0JW/wypapeq.png

[benwaggoner]

When a codec gets better bidirectional prediction, you'd expect the I/P to b ratio to get higher. Visually do you see any issues before or after?

SSIM isn't a particularly sensitive metric, and the same QP can look different in different codecs. At this early stage, we need to be relying on visual examination. If we have to use metrics, the newest version of VMAF is the best available for SDR content.

[birdie]

An ffmpeg fork with VVC decoding support: https://github.com/tbiat/FFmpeg

Not a huge fan since it's not exactly clear how it's been patched. Separate patches against the known ffmpeg git snapshot would be better.

[Jamaika]

An ffmpeg fork with VVC decoding support: https://github.com/tbiat/FFmpeg

Not a huge fan since it's not exactly clear how it's been patched. Separate patches against the known ffmpeg git snapshot would be better.
OpenVVC is a bit strange.https://github.com/OpenVVC/OpenVVC/commit/3371be46a526fa5f29ffdcf7836b5f096dabf895

dpb.c:1183:28: warning: passing argument 1 of 'pthread_mutex_lock' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
1183 | pthread_mutex_lock(&decoded_ctus->ref_mtx);
| ^~~~~~~~~~~~~~~~~~~~~~
In file included from dec_structures.h:5,
from ovdec_internal.h:8,
from ovdpb.h:8,
from dpb.c:10:
c:\msys1200\x86_64-w64-mingw32\include\pthread.h:1039:69: note: expected 'struct pthread_mutex_t_ **' but argument is of type 'struct pthread_mutex_t_ * const*'
1039 | PTW32_DLLPORT int PTW32_CDECL pthread_mutex_lock (pthread_mutex_t * mutex);
| ~~~~~~~~~~~~~~~~~~^~~~~

drv.c:3:45: error: unknown type name 'VVCMV'
3 | fill_mvp_map(struct VVCMVCtx *const mv_ctx, VVCMV mv,
| ^~~~~
drv.c:17:114: error: unknown type name 'VVCMV'
17 | fill_dbf_mv_map_b(struct DBFInfo *const dbf_info, struct VVCMVCtx *const mv_ctx, struct VVCMVCtx *const mv_ctx1, VVCMV mv,
| ^~~~~
drv.c:57:80: error: unknown type name 'VVCMV'
57 | fill_dbf_mv_map(struct DBFInfo *const dbf_info, struct VVCMVCtx *const mv_ctx, VVCMV mv,
| ^~~~~
drv.c:93:8: error: unknown type name 'VVCMergeInfo'
93 | static VVCMergeInfo
| ^~~~~~~~~~~~
drv.c:94:14: error: unknown type name 'VVCLocalContext'
94 | derive_mvp_b(VVCLocalContext *const lc_ctx,
| ^~~~~~~~~~~~~~~
drv.c:95:20: error: unknown type name 'VVCPartSize'
95 | const VVCPartSize *const part_ctx,
| ^~~~~~~~~~~
drv.c:98:14: error: unknown type name 'VVCMV'
98 | VVCMV mvd0, VVCMV mvd1,
| ^~~~~
drv.c:98:26: error: unknown type name 'VVCMV'
98 | VVCMV mvd0, VVCMV mvd1,
| ^~~~~
drv.c:99:14: error: unknown type name 'uint8_t'
99 | uint8_t mvp_idx0, uint8_t mvp_idx1,
| ^~~~~~~
drv.c:1:1: note: 'uint8_t' is defined in header '<stdint.h>'; did you forget to '#include <stdint.h>'?
+++ |+#include <stdint.h>
1 |
drv.c:99:32: error: unknown type name 'uint8_t'
99 | uint8_t mvp_idx0, uint8_t mvp_idx1,
| ^~~~~~~
drv.c:99:32: note: 'uint8_t' is defined in header '<stdint.h>'; did you forget to '#include <stdint.h>'?
drv.c:100:14: error: unknown type name 'uint8_t'
100 | uint8_t inter_dir)
| ^~~~~~~
drv.c:100:14: note: 'uint8_t' is defined in header '<stdint.h>'; did you forget to '#include <stdint.h>'?
drv.c:147:17: error: unknown type name 'VVCLocalContext'
147 | update_mv_ctx_b(VVCLocalContext *const lc_ctx, struct VVCInterCtx *const inter_ctx,
| ^~~~~~~~~~~~~~~
drv.c:148:23: error: unknown type name 'VVCPartSize'
148 | const VVCPartSize *const part_ctx,
| ^~~~~~~~~~~
drv.c:149:23: error: unknown type name 'VVCMV'
149 | const VVCMV mv0, const VVCMV mv1,
| ^~~~~
drv.c:149:40: error: unknown type name 'VVCMV'
149 | const VVCMV mv0, const VVCMV mv1,
| ^~~~~
drv.c:152:17: error: unknown type name 'uint8_t'
152 | uint8_t inter_dir)
| ^~~~~~~


nvcl_hrd.c:5:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
5 | {
| ^
nvcl_hrd.c:11:3: warning: data definition has no type or storage class
11 | } OVSubLayerHRD;
| ^~~~~~~~~~~~~
nvcl_hrd.c:11:3: warning: type defaults to 'int' in declaration of 'OVSubLayerHRD' [-Wimplicit-int]
nvcl_hrd.c:36:50: error: unknown type name 'subLayerId'
36 | sublayer_hrd_parameters(OVNVCLReader *const rdr, subLayerId)
| ^~~~~~~~~~
nvcl_hrd.c:55:52: error: unknown type name 'firstSubLayer'
55 | ols_timing_hrd_parameters(OVNVCLReader *const rdr, firstSubLayer, MaxSubLayersVal)
| ^~~~~~~~~~~~~
nvcl_hrd.c:55:67: error: unknown type name 'MaxSubLayersVal'
55 | ols_timing_hrd_parameters(OVNVCLReader *const rdr, firstSubLayer, MaxSubLayersVal)
| ^~~~~~~~~~~~~~~
nvcl_hrd.c:82:1: warning: return type defaults to 'int' [-Wimplicit-int]
82 | general_timing_hrd_parameters(OVNVCLReader *const rdr)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
nvcl_hrd.c: In function 'general_timing_hrd_parameters':
nvcl_hrd.c:85:5: error: 'ghrd' undeclared (first use in this function)
85 | ghrd->num_units_in_tick = nvcl_read_bits(rdr, 32);
| ^~~~
nvcl_hrd.c:85:5: note: each undeclared identifier is reported only once for each function it appears in

[ksec]

VVenC 1.2.0 released

https://github.com/fraunhoferhhi/vvenc/releases/tag/v1.2.0

major efficiency improvement for faster, minor speedups for fast and medium
allowing separate encoding of first and second pass in 2pRC (using a statistics data file)
improvements to single picture and low-rate rate-control
added support for packed 10 bit YUVs
added a balanced IDR refresh mode (using IDR_W_RADL in first intra period)
improvements to ALF, DMVR, error handling and others
various fixes and cleanups

[birdie]

VVenC 1.2.0 released

https://github.com/fraunhoferhhi/vvenc/releases/tag/v1.2.0

And we still have zero players. I've only found VQProbe (https://vicuesoft.com/vq-probe) but it's an analyzer, not a player, so I've no idea whether it can play audio or play in full screen mode.

[Balling]

An ffmpeg fork with VVC decoding support: https://github.com/tbiat/FFmpeg

Not a huge fan since it's not exactly clear how it's been patched. Separate patches against the known ffmpeg git snapshot would be better.

There is also this. https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=3487

[birdie]

There is also this. https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=3487

This patchset allows ffmpeg to recognize VVC bitstream data, it doesn't contain an actual decoder implementation either directly or though an external library. IOW it's useless.

[contemporarymind]

And we still have zero players. I've only found VQProbe (https://vicuesoft.com/vq-probe) but it's an analyzer, not a player, so I've no idea whether it can play audio or play in full screen mode.

There's a couple proof-of-concept players by now based on vvdec, even for the browser. no audio though...

https://github.com/bitmovin/vvDecPlayer
https://github.com/fraunhoferhhi/vvdecWebPlayer

[Balling]

This patchset allows ffmpeg to recognize VVC bitstream data, it doesn't contain an actual decoder implementation either directly or though an external library. IOW it's useless.

The trace_headers implementation is always the first one! There is no point to implement presenter if bitstream parser is not done. same for AV1 (there is a very simple low overheader parser in ffmpeg not used for decoding) and also there is a parser of HDR10+, no support for presenting HDR10+ yet.

[birdie]

So, MulticoreWare now lists x266 encoder (https://multicorewareinc.com/what-we-deliver/video-codecs/x266-vvc-encoder/) among its products, yet its git repo (https://bitbucket.org/multicoreware/x266/src/master/) continues to be members only, what's going on? Have I missed something?

[Dann0245]

So, MulticoreWare now lists x266 encoder (https://multicorewareinc.com/what-we-deliver/video-codecs/x266-vvc-encoder/) among its products, yet its git repo (https://bitbucket.org/multicoreware/x266/src/master/) continues to be members only, what's going on? Have I missed something?

They listed on their website many months ago.

I don't know but they seem to need more time for the first version of x266 than x265, and there is no any player support yet.

[birdie]

The latest MSU codecs comparison: https://compression.ru/video/codec_comparison/2021/main_report.html at FullHD.

TLDR: H.266 shines except for high-speed/RT encoding where H.265 implementations are still better.

Looks like you can test their codec for free: https://www.huaweicloud.com/intl/en-us/product/mpc.html - I want to try this.

[Selur]

So the conclusion of that comparision is that in theory you get the best qulits with these three encoders: HW266, S266_vX, Tencent266 but since they are closed source and not available to try or buy you can't use them.

[benwaggoner]

They listed on their website many months ago.

I don't know but they seem to need more time for the first version of x266 than x265, and there is no any player support yet.
The complexity jump in new tools is a lot bigger in absolute terms than from H.264 to H.265, so that's more new code to write. Relative complexity jump is about on par.

[MoSal]

So the conclusion of that comparision is that in theory you get the best qulits with these three encoders: HW266, S266_vX, Tencent266 but since they are closed source and not available to try or buy you can't use them.

On the other hand, it's the first time I hear about xin26x which could develop into a good encoder suite if the developers ever get to a stage where some effort is spent on subjective tuning.

[RanmaCanada]

So the conclusion of that comparision is that in theory you get the best qulits with these three encoders: HW266, S266_vX, Tencent266 but since they are closed source and not available to try or buy you can't use them.

Sadly it was the same thing with HEVC when it was being tested. You can't buy literally 90% of the codecs or encoders they used, so it's geared more towards industrial aspects like security camera or broadcasting.

[foxyshadis]

What I've noticed is relatively interesting. So basically we all know that any encoder is gonna assign more bits to the I than it will to the P and B, however if we compare it with the H.265 stream, we can see that x265 is spreading those a bit more evenly than VVEnc is for H.266. Let me be more specific: basically, since the final encode is gonna be CBR, I can see how "large" each frame is gonna be in the GOP and what I've noticed is that in H.265 we have like: Intra large, P and B a bit smaller, while in H.266 we have like: Intra very large, P and B much smaller to have the same bitrate in the end in both encodes, which means that either VVEnc better detected the blocks and macroblocks across the scene and was able to use motion compensation in a better way OR it's using some of the new psychovisual features so that it "thinks" that it doesn't need as much bitrate, but it actually does. What I can say, though, is that in motion, if you look closely, you can see the difference as you look at the grain pattern in the back which appears to be blurrier than other frames in the exact same points in which the SSIM score drops, so it looks like something didn't go as expected, but from my experience I feel like this has something to do with the VVEnc implementation rather than H.266 itself. I'm pretty sure that we're gonna see the bitrate much more evenly spread (and much closer to how it's spread in x265) in x266 when it will become available.
Rate control in general always seems to be one of the biggest bugbears of any prototype encoder. SSIM is a flawed measure but oscillating that much is absolutely going to be visible, the same way Xvid and early versions of x264 worked. It's a painful amount of iteration, trying to optimize for a whole spectrum of use cases and completely unknown upcoming features, so I can understand why it doesn't get as much love as say, a new SIMD optimization that can be directly benched against the C as an immediate improvement.

[benwaggoner]

Rate control in general always seems to be one of the biggest bugbears of any prototype encoder. SSIM is a flawed measure but oscillating that much is absolutely going to be visible, the same way Xvid and early versions of x264 worked. It's a painful amount of iteration, trying to optimize for a whole spectrum of use cases and completely unknown upcoming features, so I can understand why it doesn't get as much love as say, a new SIMD optimization that can be directly benched against the C as an immediate improvement.
Yep. Rate Control is one of the most complex and nuanced features of real-world encoders. It's got a lot of psychovisual aspects, not just pure engineering. And choices made in each frame can propagate through the rest of the GOP, and getting that right is super complex. One of the secret weapons of x264 was cu-tree (ctu-tree in x265)

[Dann0245]

I hope Multicoreware could talk more about the current state of x266 encoder at IBC 2021!

https://multicorewareinc.com/news/meet-us-at-ibc-2021/

or even better, release x266 0.1 version.

[birdie]

MediaTek has announced Pentonic 2000 SoC (https://www.prnewswire.com/news-releases/mediatek-announces-new-pentonic-smart-tv-family-with-new-pentonic-2000-for-flagship-8k-120hz-tvs-301428273.html) which supports VVC. Finally!

[Jamaika]

For me this is the paranoia of the techno of the Asiatic world. Buy 8K 55 "- 98" for your street business as an advertisement. There are no winters so knock the wall over the TV. 4K magnified to 8K has pixels. Oh dear, then we'll add neo qled or evo oled so as not to scare the client off the street.
What for a home user 4K below 48 ". It does not matter most of this technology. Will the creators change old movies on vvc? They will not. Here only fans of mass events benefit.
What about professional 8K cameras when webcam or youtube reigns? For VIPs.
https://www.samsung.com/pl/tvs/qled-tv/highlights/
https://www.lg.com/pl/oled-tv/2021/self-lit-pixels?cmpid=2021HQSEM_OLED-TV_PL_Google_OLED_Core-mid_Broad_OLED_k0002-added0611_pc_2021&gclid=EAIaIQobChMI5Iv6s_mm9AIVh94YCh2dqwY5EAAYAiAAEgLi7PD_BwE&gclsrc=aw.ds
I don't know what the Panansonic has in hiding, but in Central Europe it isn't taken into account.
Sony and Sharp used to be the leaders. Where are they on the silk road?

[Dann0245]

To play VVC file with VLC.

Download O266 lib, libo266dec.dll file (by tencent): https://multimedia.tencent.com/resources/vvc-player

Put libo266dec.dll file into dir: VLC\plugins\codec

then play *.266 file

But you may see the framerate is incorrect, you need encode with new VVenC build, which has have new --fps switch for exact framerate.

[benwaggoner]

For me this is the paranoia of the techno of the Asiatic world. Buy 8K 55 "- 98" for your street business as an advertisement. There are no winters so knock the wall over the TV. 4K magnified to 8K has pixels. Oh dear, then we'll add neo qled or evo oled so as not to scare the client off the street.
What for a home user 4K below 48 ". It does not matter most of this technology. Will the creators change old movies on vvc? They will not. Here only fans of mass events benefit.
Optical disc development ended with UHD Blu-ray, so 4K HDR HEVC. But streaming services absolutely adopt new codecs when they have sufficient installed base and compression efficiency improvements to merit it. And encoding is done from a high quality mezzanine, so the content creators don't need to do anything for customers to get the benefit of a new codec.

We won't be watching much H.264/HEVC/VP9 in 10 years!

What about professional 8K cameras when webcam or youtube reigns?[/QUOTE]
Used heavily for premium content creation. YouTube is a slice of the market, but user-generated content as a business pales in comparison to that for premium TV and movies.

[FranceBB]

What about professional 8K cameras when webcam or youtube reigns?

Reign where? Red Monstro 8K cameras have been around for quite some time now ehehehehe
I mean, a major licensors can afford to spend 60k for the camera corpse and a bit more for the lenses etc.
Over here (and keep in mind that we're broadcasters, so our productions are smaller - although we have made some documentaries and tv series and we might have a surprise for Christmas) we're still living with 4K as we're largely based on Canon C300 for documentaries and Arri Alexa LF for TV Series, so I think the major licensors, the big names that populate the market, would have no problem spending the extra buck, going the extra mile and start producing 8K contents soon-ish.

[benwaggoner]

Reign where? Red Monstro 8K cameras have been around for quite some time now ehehehehe
I mean, a major licensors can afford to spend 60k for the camera corpse and a bit more for the lenses etc.
Over here (and keep in mind that we're broadcasters, so our productions are smaller - although we have made some documentaries and tv series and we might have a surprise for Christmas) we're still living with 4K as we're largely based on Canon C300 for documentaries and Arri Alexa LF for TV Series, so I think the major licensors, the big names that populate the market, would have no problem spending the extra buck, going the extra mile and start producing 8K contents soon-ish.
Do you mean shooting in 8K and post in 4K, or 8K through to a mezzanine file?

Shooting in 8K, sure. That's been happening for a while, and a number of movies and TV shows shot with 8K cameras are already available.

Post and distribution in 8K is a whole other matter, and I'm not aware of any real-world titles using it or even seriously contemplating doing so. The extra costs far outweigh any potential added market value. 4x more pixels mean new monitors (and there aren't any DisplayPort 8K HDR monitors), 4x the storage, 4x the RAM, 4x longer rendering, projectors can't be used for previews, and a whole lot of other hassles. Plus, since 4K and 8K look identical for the 99.9% of premium content that's at 24p, determining that 8K is actually working is a huge challenge.

Valuable 8K is a lot more likely at 120p. But that's pushed the delta up to 20x storage, 20x render time, another generation of studio monitors, etcetera. Moore's Law is a wonderful thing, so even if 20x is impossible today it'll be no big deal in 10-12 years.

[excellentswordfight]

Do you mean shooting in 8K and post in 4K, or 8K through to a mezzanine file?

Shooting in 8K, sure. That's been happening for a while, and a number of movies and TV shows shot with 8K cameras are already available.

Post and distribution in 8K is a whole other matter, and I'm not aware of any real-world titles using it or even seriously contemplating doing so. The extra costs far outweigh any potential added market value. 4x more pixels mean new monitors (and there aren't any DisplayPort 8K HDR monitors), 4x the storage, 4x the RAM, 4x longer rendering, projectors can't be used for previews, and a whole lot of other hassles. Plus, since 4K and 8K look identical for the 99.9% of premium content that's at 24p, determining that 8K is actually working is a huge challenge.

Valuable 8K is a lot more likely at 120p. But that's pushed the delta up to 20x storage, 20x render time, another generation of studio monitors, etcetera. Moore's Law is a wonderful thing, so even if 20x is impossible today it'll be no big deal in 10-12 years.
The part that made Moore's Law such a wonderful thing is dead, and that is that it factored in price. Yes we are still seeing an rather impressive increase in transistor count, but it now comes at a huge price as the cost per transistor for modern advanced nodes is nowhere near what Moore described. This is extra obvious when you look at GPUs (even if we exclude the inflated prices atm), when moor's law was alive and well you could pretty much just wait for semiconductor improvements and get a huge performance increase from just the transistor increase alone at the same manufacturing cost, now we even see new nodes with worse transistor price then prior generations, we can just expect the prices to continue to climb if we want the performance keep scaling from transistors alone.

There are ofc other tech areas that improves on this in other ways, just look at what apple is doing with their silicon and ecosystem, and what you are able to do on those machines in terms of video compared to what was needed for that a couple of years ago. Not that their more recent chips are not impressive when it comes to transistors as well, I think that Apple is in a rather unique situation here; they are so profitable elsewere and has such a huge volume so it wouldnt surprise me if they actually have relatively low margins on these parts.

[FranceBB]

just look at what apple is doing with their silicon and ecosystem, and what you are able to do on those machines in terms of video compared to what was needed for that a couple of years ago. Not that their more recent chips are not impressive when it comes to transistors as well, I think that Apple is in a rather unique situation here; they are so profitable elsewere and has such a huge volume so it wouldnt surprise me if they actually have relatively low margins on these parts.

What is Apple doing? They're largely based on ARM CPUs with x86 emulation. Even if the emulation is well done, they will never ever be as efficient as running an x86 application natively and so far ARM isn't really good for video encoding, it just isn't.

[benwaggoner]

The part that made Moore's Law such a wonderful thing is dead, and that is that it factored in price. Yes we are still seeing an rather impressive increase in transistor count, but it now comes at a huge price as the cost per transistor for modern advanced nodes is nowhere near what Moore described. This is extra obvious when you look at GPUs (even if we exclude the inflated prices atm), when moor's law was alive and well you could pretty much just wait for semiconductor improvements and get a huge performance increase from just the transistor increase alone at the same manufacturing cost, now we even see new nodes with worse transistor price then prior generations, we can just expect the prices to continue to climb if we want the performance keep scaling from transistors alone.

There are ofc other tech areas that improves on this in other ways, just look at what apple is doing with their silicon and ecosystem, and what you are able to do on those machines in terms of video compared to what was needed for that a couple of years ago. Not that their more recent chips are not impressive when it comes to transistors as well, I think that Apple is in a rather unique situation here; they are so profitable elsewere and has such a huge volume so it wouldnt surprise me if they actually have relatively low margins on these parts.
Yeah, no doubt that Moore's Law predictions have changed a bunch. We are still seeing good compute/$ improvements over time, but it comes from an aggregation of improvements, not just more transistors and higher clock speeds anymore.

For the film industry, it can be as much about what's possible as how much it costs. Lots of tools that can do 4Kp24 today simply don't have any way to scale to 8Kp120 at any costs. You can squint and imagine how a cluster of beefy servers chock full of a6000 GPUs and clever tiling software could do the same thing. But unless that software and hardware is available, it just isn't possible. And regressing from real-time previews to "I'm going to render the shot now, should be done after lunch" is a huge deal.

It's the same way you can't buy a gaming rig that can do 8Kp120 for 8x (or 80x) the cost of one that can do 4Kp60. There is only so much parallelism that can be taken advantage of by the underlying software architecture before an Amdahl's law limit gets hit. SLI was never 2x the perf, nor was TLI.

[excellentswordfight]

What is Apple doing? They're largely based on ARM CPUs with x86 emulation. Even if the emulation is well done, they will never ever be as efficient as running an x86 application natively and so far ARM isn't really good for video encoding, it just isn't.
I'm referring to transistors here, were Apple has an CPU architecture that has an very impressive IPC without spending relatively speaking an huge amount of transistors to achieve it. I.e. we can still see impressive technical advancements without Moores Law, and Apples SoC is very much impressive, regardless of how good (or bad) it is for the sw-encoders available atm.

And sw-encoding is not the only factor in the workflow if 8k will become valid or not, I have tried the M1 for video editing 4k HEVC & Prores files, and what that SoC achieves at this powerdraw is simply astounding. And its not just the CPU-cores I'm refering to, it's all the other stuff on the SoC as well in combination with stuff like Metal (or what Intel is doing with oneAPI) that really displays that there is a promising future even without Moores Law.

Yeah, no doubt that Moore's Law predictions have changed a bunch. We are still seeing good compute/$ improvements over time, but it comes from an aggregation of improvements, not just more transistors and higher clock speeds anymore.

Yeah the breakdown of Dennard scaling (https://en.wikipedia.org/wiki/Dennard_scaling) isnt helping either :/

[benwaggoner]

What is Apple doing? They're largely based on ARM CPUs with x86 emulation. Even if the emulation is well done, they will never ever be as efficient as running an x86 application natively and so far ARM isn't really good for video encoding, it just isn't.
The amount of x86 emulation on the M1 processors is dropping rapidly, with lots of native apps already out and more coming.

x265 itself got a bunch of ARM optimization check-ins this year that have more than doubled encoding fps on M1.

Talking to colleagues deep in this stuff, there isn't anything fundamentally better about the x86-64 instruction set for encoding. It's more than Intel and AMD build big beefy CPUs with lots and lots of cores and cache and SIMD.

[benwaggoner]

I'm referring to transistors here, were Apple has an CPU architecture that has an very impressive IPC without spending relatively speaking an huge amount of transistors to achieve it. I.e. we can still see impressive technical advancements without Moores Law, and Apples SoC is very much impressive, regardless of how good (or bad) it is for the sw-encoders available atm.

And sw-encoding is not the only factor in the workflow if 8k will become valid or not, I have tried the M1 for video editing 4k HEVC & Prores files, and what that SoC achieves at this powerdraw is simply astounding. And its not just the CPU-cores I'm refering to, it's all the other stuff on the SoC as well in combination with stuff like Metal (or what Intel is doing with oneAPI) that really displays that there is a promising future even without Moores Law.
Yeah, making a big desktop-caliber SoC allowed for integration of RAM and high performance GPU in a single chip. And the tight coupling between HW and SW that Apple delivers means that the full capabilities of the new design are leveraged.

A metaphor would be Xbox Series/PS5-only games. They can rely on SSD storage, DirectStorage like SSD to GPU transfers, etc within a tightly defined architecture. Like the M1, they can outperform a general purpose computer setup at a fraction of the cost.

[FranceBB]

Lots of tools that can do 4Kp24 today simply don't have any way to scale to 8Kp120 at any costs.

By the way, not really related, but as much as I wanted the proposal for broadcasting PAL 8K to be 100fps and for NTSC 8K to be 120fps, it looks like it's going to be the same as the "old" 4K specs, so 50p and 60p. There's still an argument about 10bit VS 12bit but looks like that one is gonna be scrapped as well and it will still be 10bit. :(
Nothing official, just rumours, but still...



x265 itself got a bunch of ARM optimization check-ins this year that have more than doubled encoding fps on M1.

I actually noticed it (no I'm not an Apple user, I just remember seeing the commits and something related in the x265 topic).


Talking to colleagues deep in this stuff, there isn't anything fundamentally better about the x86-64 instruction set for encoding. It's more than Intel and AMD build big beefy CPUs with lots and lots of cores and cache and SIMD.

Really? I thought ARM were meant for mobile use and had fewer transistors and those transistors were actually made to use the smallest amount of energy as possible at the expense of performances. I also thought they had different registers made just for stuff that you use in a mobile like TLS computations for websites and some ai things for assistants etc. Of course something like an encoder could make use of some of those registers as well for its calculations, hence speeding things up with the manually written intrinsics like x265 has done, but I thought the ARM registers were no match for the x86_64 ones (SSE/AVX). If what you're saying is true, this opens the door to lots of new scenarios. :eek:

[birdie]

Yet another topic where people are talking about a Moore's "Law" when in reality it's never been anything but an observation.

[birdie]

Bitmovin has released its Annual Video Developer Report for 2021 (https://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=150364).

[benwaggoner]

Yet another topic where people are talking about a Moore's "Law" when in reality it's never been anything but an observation.
Indeed. And one which has required a lot of reformulation over the years to keep meaningful.

But the general point that we can anticipate increasing compute/$ for at least a couple more decades is important, even if the rate of improvement is slowing down. Digital media stuff consistently gets some of the biggest generation-on-generation performance/efficiency improvements, as we can leverage a whole lot of SIMD and parallelism.

[ksec]

Bitmovin has released its Annual Video Developer Report for 2021 (https://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=150364).

We conducted the survey from July 7th through August 22nd, 2021. 538 video developers and industry experts from 65 countries participated.

While the Bitmovin Developer Survey is open for everyone to participate and we are posting it industry-wide, we want to preface that the results might be slightly skewed towards the Bitmovin customer base.

Not really useful in terms of the whole industry "codec usage" but for me there were two interesting point.

1. Quality is not even the top 5 features respondent care about. Which is what I have been saying for sometime, if you want higher quality, go higher bitrate or better codec than H.264. It is no longer much a tech issue, but a cost issue.

2. It is not only me and a small group of people screaming for better low latency video. Live Streaming is the one that makes money, and also the one which requires most attention from codec usage.

[benwaggoner]

I also noted that, for all the pessimism around it, HEVC had a bigger year-on-year market share growth than AV1.

I was pleasantly surprised to see as much AC-4 and MPEG-H as there was as well.

[FranceBB]

It is no longer much a tech issue, but a cost issue.

CDNs ain't cheap and management likes the "same quality, less bitrate/less expenses" sentence...

[benwaggoner]

CDNs ain't cheap and management likes the "same quality, less bitrate/less expenses" sentence...
Depends on the market. Premium subscription services are a lot more likely to spend bits to improve quality. UHD and 4K content are a key differentiator from broadcast and cable.

[FranceBB]

Depends on the market. Premium subscription services are a lot more likely to spend bits to improve quality. UHD and 4K content are a key differentiator from broadcast and cable.

Eheheheh you're at Amazon so you literally have everything implemented already. If there's something you don't fall short of is bandwidth in cloud servers scattered across the globe :P

[birdie]

An interview with Dr. Dmitriy Vatolin (https://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=150562) is the Head of the Moscow State University Graphics and Media Lab about video codecs.

[Blankmedia]

For all the known and unknown in this, all we can say in regard to vvc is that we are gonna need more Ram.

Envoyé de mon Pixel 6 en utilisant Tapatalk

[Dann0245]

Does anyone hear any thing about x266 encoder from Multicoreware at CES 2022?

If no, x266 seem to be heavily delayed.

[benwaggoner]

Does anyone hear any thing about x266 encoder from Multicoreware at CES 2022?

If no, x266 seem to be heavily delayed.
CES would be an odd show to market a video encoder. That's much more of a NAB thing.

[birdie]

Does anyone hear any thing about x266 encoder from Multicoreware at CES 2022?

If no, x266 seem to be heavily delayed.

To be honest I've got zero faith in this codec.

Recently I tried to recompress an SD source (interlaced MPEG2 at 10Mbps) using x264, x265 and libaom and x264 came out on top by a wide margin. Both x265 and AV1 simply destroyed the source and even x264 @3Mbps struggled. I didn't venture to go below 3000.

H.266 might excel at 4K/8K but for SD/HD x264 is still the king which is really weird considering all the new intra/inter algos in new codecs.

[Dann0245]

To be honest I've got zero faith in this codec.

Recently I tried to recompress an SD source (interlaced MPEG2 at 10Mbps) using x264, x265 and libaom and x264 came out on top by a wide margin. Both x265 and AV1 simply destroyed the source and even x264 @3Mbps struggled. I didn't venture to go below 3000.

H.266 might excel at 4K/8K but for SD/HD x264 is still the king which is really weird considering all the new intra/inter algos in new codecs.

I think the new codecs aren't impressive with SD resolution because of big block (x265 CTU and AV1 superblock). x264 in the same term call macroblock, is only 16x16.

So to make x265 handling SD resolution well, I use small CTU

--ctu 16 --max-tu-size 16 --qg-size 16

or

--ctu 16 --max-tu-size 8 --qg-size 8

disable recursion skip: --rskip 0 might force x265 deep dive into small detail.

raise --qcom from 0.6 to 0.8, 0.9 to improve high motion scene.

turn off smooth filter: --no-sao, --no-strong-intra-smoothing

I think these settings should help with SD, except if your source have ton of noises

with AV1 encoder, particular aomenc, I can only reduce superblock to 64x64, and AV1 has too many filters which make result too blurry. As I test all AV1 encoders are so terrible at high motion scene.


All new codecs love high resolution with big block, by now the block increases to 128x128.

[Boulder]

turn off smooth filter: --no-sao, --no-strong-intra-smoothing

--strong-intra-smoothing is not a smoothing filter. It actually should improve the retention of details.

[Dann0245]

CES would be an odd show to market a video encoder. That's much more of a NAB thing.

On MulticoreWare website has a place about CES 2022

https://multicorewareinc.com/news/join-us-at-ces-2022/

Because of that, so I think they will talk about their products, also something about x266

--strong-intra-smoothing is not a smoothing filter. It actually should improve the retention of details.

I don't know that. I usually disable when encode grain or high bitrate.

[ksec]

To be honest I've got zero faith in this codec.

Recently I tried to recompress an SD source (interlaced MPEG2 at 10Mbps) using x264, x265 and libaom and x264 came out on top by a wide margin. Both x265 and AV1 simply destroyed the source and even x264 @3Mbps struggled. I didn't venture to go below 3000.

H.266 might excel at 4K/8K but for SD/HD x264 is still the king which is really weird considering all the new intra/inter algos in new codecs.

New codec excel at low bitrate. Think HD at 1Mbps or 4K at 4Mbps. x264 had a heck of a team and time tuning for SD and 10Mbps bitrate. It is more of an encoder issue and investment into making it good at those scenario, rather than the codec itself.

[Boulder]

The world is moving towards digital media from the old physical media. That's why the development concentrates mainly on creating a watchable low bitrate stream from the source instead of replicating it accurately.

[birdie]

No idea what to make of it: https://www.techpowerup.com/290799/access-advance-announces-the-initial-group-of-vvc-h-266-video-patent-pool-licensors

18 months after finalizing the codec they are excited about ... licensing. Not adoption, not products, not software ...

That sounds almost [don't want to get a ban here].

[benwaggoner]

No idea what to make of it: https://www.techpowerup.com/290799/access-advance-announces-the-initial-group-of-vvc-h-266-video-patent-pool-licensors

18 months after finalizing the codec they are excited about ... licensing. Not adoption, not products, not software ...

That sounds almost [don't want to get a ban here].
Hey, if we are getting a single patent pool for VVC, that is a huge development. HEVC had three, which added a lot to confusion after the simple, public terms MPEG-LA had for H.264.

There's no doubt that VVC is technically the best video codec standard available today, by a substantial margin. Licensing problems are the main reasons why it wouldn't be successful.

[nevcairiel]

No doubt MPEG-LA will also have one again, so thats at least two again.

Unless the technical standardization also enforces patent sanity for a future codec, there will never be one single point for this again, its just too much money.

[PCU]

I'm sure most streaming services will use AV1 or AV2 in the future unless MPEG-LA (or something like that) is behind it.

[hajj_3]

Qualcomm were the main company that prevented a single patent pool on h265, i highly doubt they will join access advance until companies like google pressure qualcomm. Google owns android which is critically important for qualcomm's products. Google could easily force qualcomm to agree with their power over android if they wanted to.

[benwaggoner]

Qualcomm were the main company that prevented a single patent pool on h265, i highly doubt they will join access advance until companies like google pressure qualcomm. Google owns android which is critically important for qualcomm's products. Google could easily force qualcomm to agree with their power over android if they wanted to.
If Google had that much power over Qualcomm, there would be AV1 decoders in Qualcomm SoCs...

[ksec]

Qualcomm were the main company that prevented a single patent pool on h265, i highly doubt they will join access advance until companies like google pressure qualcomm. Google owns android which is critically important for qualcomm's products. Google could easily force qualcomm to agree with their power over android if they wanted to.

That is not strictly true. Qualcomm was "one" of them, not the main. There were lots of companies in the MPEG-LA camp that prevented the single pool. Including Apple.

In terms of Smartphone, it is Qualcomm which has the power. You want 4G / 5G along with other Modem technology? You need to deal with Qualcomm no matter what. And I would be surprised if that patent agreement doesn't include video compression, since Qualcomm lumped everything from CPU, power management to other things all in one package anyway.

AV1 and VVC will likely live side by side in the future. Since the industry doesn't seems to agree on anything.

[benwaggoner]

That is not strictly true. Qualcomm was "one" of them, not the main. There were lots of companies in the MPEG-LA camp that prevented the single pool. Including Apple.

In terms of Smartphone, it is Qualcomm which has the power. You want 4G / 5G along with other Modem technology? You need to deal with Qualcomm no matter what. And I would be surprised if that patent agreement doesn't include video compression, since Qualcomm lumped everything from CPU, power management to other things all in one package anyway.

AV1 and VVC will likely live side by side in the future. Since the industry doesn't seems to agree on anything.
If VVC looks like a clear market winner for premium content, that could result in Qualcomm and others not including it on their SoCs. AV1 takes a whole lot of gates, and leakage means just the existence of AV1 HW support hurts thermals and battery life some. VVC outperforms AV1 in compression while needing less mm^2. AV1 in software works well enough for short form DRM-free user generated content ala YouTube and Facebook.

[PCU]

If VVC looks like a clear market winner for premium content, that could result in Qualcomm and others not including it on their SoCs. AV1 takes a whole lot of gates, and leakage means just the existence of AV1 HW support hurts thermals and battery life some. VVC outperforms AV1 in compression while needing less mm^2. AV1 in software works well enough for short form DRM-free user generated content ala YouTube and Facebook.

AV1 is a competitor to H.265, AV2 is also a competitor to H.266. Most streaming services prefer AV1 and in the future AV2. (Only Apple is swimming in the opposite direction of the water!). This is what happened in the video game industry: using Vorbis instead of MP3/AAC/WMA/DD, etc.
But I prefer H.26x formats because comparing YouTube/Facebook/Insta/Twitter's H.264 with VP9/AV1, the quality of H.264 (call it x264) was always better. (VP9/AV1 is too blurry)

[birdie]

AV1 is a competitor to H.265, AV2 is also a competitor to H.266. Most streaming services prefer AV1 and in the future AV2. (Only Apple is swimming in the opposite direction of the water!). This is what happened in the video game industry: using Vorbis instead of MP3/AAC/WMA/DD, etc.
But I prefer H.26x formats because comparing YouTube/Facebook/Insta/Twitter's H.264 with VP9/AV1, the quality of H.264 (call it x264) was always better. (VP9/AV1 is too blurry)

VP9 encoded YouTube videos are much better than H.264 encoded ones by a large margin. Would be nice if you showed at least one where "H.264 is better".

[PCU]

VP9 encoded YouTube videos are much better than H.264 encoded ones by a large margin. Would be nice if you showed at least one where "H.264 is better".

Just download the H.264 and VP9 version of this video and compare it (download using IDM):
https://www.youtube.com/watch?v=_GOR5gvQwDI

[birdie]

Just download the H.264 and VP9 version of this video and compare it (download using IDM):
https://www.youtube.com/watch?v=_GOR5gvQwDI

The source is just 480p and is very low quality. Both encodes are quite bad but H.264 retrains a lot more details.

It's not obvious when youtube encoded the video, looks like 3.5 years ago, probably at the time their VP9 encoder was not good or/and didn't have enough bitrate.

20092622 Oct 25 2018 'Simple Plan - I'\''m Just A Kid (Official Video)-_GOR5gvQwDI.mp4'
12959041 Oct 25 2018 'Simple Plan - I'\''m Just A Kid (Official Video)-_GOR5gvQwDI.webm'

[PCU]

The source is just 480p and is very low quality. Both encodes are quite bad but H.264 retrains a lot more details.

It's not obvious when youtube encoded the video, looks like 3.5 years ago, probably at the time their VP9 encoder was not good or/and didn't have enough bitrate.

20092622 Oct 25 2018 'Simple Plan - I'\''m Just A Kid (Official Video)-_GOR5gvQwDI.mp4'
12959041 Oct 25 2018 'Simple Plan - I'\''m Just A Kid (Official Video)-_GOR5gvQwDI.webm'

What program did you download with?
Also, AV1 still is bad, just download one of the Gamers Nexus videos and check how bad is the AV1 version.

[birdie]

What program did you download with?
Also, AV1 still is bad, just download one of the Gamers Nexus videos and check how bad is the AV1 version.

https://github.com/ytdl-org/youtube-dl

or its more advanced fork

https://github.com/yt-dlp/yt-dlp

[LigH]

Also remember: YouTube recodes all videos with a rather constant bitrate as target for streaming over a limited bandwidth; this returns anything but optimal quality per bitrate. Different codecs may use substantially different strategies to distribute the bitrate across a video playback buffer. Especially a patent-free codec may need to avoid patented algorithms which may be useful for this specific use case. Disclaimer: I may or may not be wrong in my claims.

[PCU]

20 decade is the decade of streaming!

[Gravitator]

If VVC looks like a clear market winner for premium content, that could result in Qualcomm and others not including it on their SoCs. AV1 takes a whole lot of gates, and leakage means just the existence of AV1 HW support hurts thermals and battery life some. VVC outperforms AV1 in compression while needing less mm^2. AV1 in software works well enough for short form DRM-free user generated content ala YouTube and Facebook.

At what settings and resolution? Is there a comparative demo available?

[ksec]

If VVC looks like a clear market winner for premium content, that could result in Qualcomm and others not including it on their SoCs. AV1 takes a whole lot of gates, and leakage means just the existence of AV1 HW support hurts thermals and battery life some. VVC outperforms AV1 in compression while needing less mm^2. AV1 in software works well enough for short form DRM-free user generated content ala YouTube and Facebook.

Both VVC and AV1 decoding are definitely coming in the next Qualcomm SoC flagship update. It was suppose to be 2021 but the IP got delayed. ( Not sure about encoding, especially AV1 )

Die Size and Area are less of a problem with leading edge node. But yes thermals and energy usage. Especially Apple which has a stringent requirement. Both VP9 and HEVC decode 4K content on Apple SoC with less than 150mW. There are three ( or four ) hardware decoding IP, but I am not aware of any of them that offer this low level of of AV1 decoding energy usage. And Samsung just announced Exynos 2200 with AV1 decoding, but no EVC decoding or encoding support.

But I am getting a little frustrated and losing patient with the lack of progress. AV2 is nowhere to be seen. x266 no show. EVC missing.

[Blue_MiSfit]

Both VVC and AV1 decoding are definitely coming in the next Qualcomm SoC flagship update.

Really? Has this been publicly confirmed?

[birdie]

Really? Has this been publicly confirmed?

I presume it's wishful thinking unless the said person works in or personally knows someone who works in Qualcomm.

[ksec]

I presume it's wishful thinking unless the said person works in or personally knows someone who works in Qualcomm.

Both Apple and Qualcomm use their in house IP and not third party IP for video / image encoding / decoding.

They are inferred from Qualcomm's public statement. New Video engine which includes VVC was originally scheduled for ( end of )2021. This got delayed and confirmed in recent Snapdragon Tech Submit.

We also know Qualcomm has engineers working on AV1 "decoding". ( Again, decoding, no idea on encoding ) And I assume it will come with their new Video Engine ( as announced with VVC ) as the video IP only gets updated once every 2 years or so. Or they could choose to not support it and have those engineers working on different things. But I find that unlikely.

And of course, roadmap changes. But all of these are inferring from public information.

[benwaggoner]

Also remember: YouTube recodes all videos with a rather constant bitrate as target for streaming over a limited bandwidth; this returns anything but optimal quality per bitrate. Different codecs may use substantially different strategies to distribute the bitrate across a video playback buffer. Especially a patent-free codec may need to avoid patented algorithms which may be useful for this specific use case. Disclaimer: I may or may not be wrong in my claims.
YouTube also does their encoding on spare cycles on Google servers, with a lot less compute/pixel than premium content encoding gets. They also encode individual segments on different hosts and assemble them after the fact. So VBV has to be conservative at the stitch points as there is no buffer state info available to use.

Plus they are highly reliant on VMAF tuning, and so have all the typical blind spots of VMAF, which tends to ignore banding and psychovisual adaptive quantization techniques.

Whatever the codec, YouTube's quality has always been lower at a given bitrate. Which makes perfect sense given their business model.

[benwaggoner]

Both Apple and Qualcomm use their in house IP and not third party IP for video / image encoding / decoding.

They are inferred from Qualcomm's public statement. New Video engine which includes VVC was originally scheduled for ( end of )2021. This got delayed and confirmed in recent Snapdragon Tech Submit.

We also know Qualcomm has engineers working on AV1 "decoding". ( Again, decoding, no idea on encoding ) And I assume it will come with their new Video Engine ( as announced with VVC ) as the video IP only gets updated once every 2 years or so. Or they could choose to not support it and have those engineers working on different things. But I find that unlikely.

And of course, roadmap changes. But all of these are inferring from public information.
It's also possible we'll see hybrid HW/SW decoders for AV1. It's not like there is premium content requiring hardware DRM AV1 content out there. AV1 is almost exclusively used for non-DRM'ed short form content so far.

[PCU]

RIP Windows Media Video!

[benwaggoner]

RIP Windows Media Video!
That funeral was held circa 2009. I was in the room when the death certificate was issued ;).

[PCU]

That funeral was held circa 2009. I was in the room when the death certificate was issued ;).

Say hello to: ProRes RAW. http://www.emoticonr.com/design/yahoo/i-do-not-want-to-see.gif

[ksec]

For those who are interested in the current HEVC / Advanced Access patent fiasco.

http://www.fosspatents.com/2022/01/access-advance-patent-pool-can-rename.html

[hajj_3]

Today MPEG-LA announced their patent pool: https://www.mpegla.com/wp-content/uploads/VVC-web.pdf

These companies are in their patent pool:

b<>com
British Broadcasting Corporation
Digital Insights Inc.
FG Innovation Company Limited
Hanwha Techwin Co., Ltd.
Koninklijke KPN N.V.
Nippon Hoso Kyokai
Orange
Siemens Corp.
Tagivan II LLC
Vidyo, Inc.

The number of patents they have is tiny, it fits on just 1 page, just 15 patents in the U.S, just 2 patents in the U.K: https://www.mpegla.com/wp-content/uploads/VVC-att1.pdf

U.K patent EP1499133 expiration: 2023-04-10
U.K patent EP2779644 expiration: 2032-11-06

U.K patent licencees will therefore have to pay to licence this patent pool just for 1 patent after april 2023 which is annoying, that patent is owned by Tagivan II LLC, their website says they are an "mpeg-la enterprise" and has an american postal address - http://www.tagivan.com

I hope that UnifiedPatents examines that last patent very carefully and tries to invalidate it.

[hajj_3]

We really need a separate forum for VVC btw.

[birdie]

We really need a separate forum for VVC btw.

There's nothing to discuss yet. No publicly available players whatsoever.

x266 is nowhere to be found.

The two available open source encoders are worse than x265.

[ksec]

JVET is currently testing a VVC extension; ECM ( Enhanced Compression Model ) which provides an additional 20% bitrate reduction over VTM 11. Along with Neural Network-based Loop Filter and Super Resolution providing additional 15-20% bitrate reduction. But at a great expense of decoding complexity.

[Dann0245]

A guy seems to work for Fraunhofer

https://2.pik.vn/202248752b3c-8f8a-4905-9833-39f58d6e4e5c.png

[ksec]

A guy seems to work for Fraunhofer

https://2.pik.vn/202248752b3c-8f8a-4905-9833-39f58d6e4e5c.png

What channel is this?

[Dann0245]

What channel is this?

AV1 channel

https://discord.gg/HSBxne3

[ksec]

AV1 channel

https://discord.gg/HSBxne3

No wonder.

[FranceBB]

Well having a VVC decoder in FFMpeg would be the first step towards wider adoption, along with Fraunhofer's VVEnc.

[nevcairiel]

Incidentally developers are also not at all interested in that format, but anyone is free to write and contribute one! :)

[benwaggoner]

We really need a separate forum for VVC btw.
We will. HEVC was split off this forum once it started to get used enough that threads discussing specific applications and tuning started to pop up.

We're not quite at that threshold yet.

[FranceBB]

Nothing in life bugs me more than an official source giving a video/live stream more than enough bitrate, but dropping half the frames

I gotta plead as "not guilty" here.
I (we) output a 25i stream which is truly interlaced and can be bobbed by TVs to 50p and in football (sports in general) each frame will always contain movement.
Why on the web it's deinterlaced to 25p instead of being bob-deinterlaced to 50p? I have no idea, it's another department that performs the consumer encode, but I'm sure they have their reasons (I just don't know them).

UHD streams are 50p directly, I wonder what they do there...
I've never actually checked, can you believe it? Eheheheh

But honestly, my job ends with the mezzanine file (if it's recorded) or the stream (if it's live) we send to the playout, what happens next is none of my business and as such I have no idea eheheheh

[birdie]

VVC Codec License Set Amid Widespread Adoption Concerns (https://www.thebroadcastbridge.com/content/entry/18075/vvc-codec-license-set-amid-widespread-adoption-concerns?cat_id=4)

DVB first to add VVC protocol for 8K video (https://www.eenewseurope.com/en/dvb-first-to-add-vvc-protocol-for-8k-video/)

[ksec]

VVC Codec License Set Amid Widespread Adoption Concerns (https://www.thebroadcastbridge.com/content/entry/18075/vvc-codec-license-set-amid-widespread-adoption-concerns?cat_id=4)

DVB first to add VVC protocol for 8K video (https://www.eenewseurope.com/en/dvb-first-to-add-vvc-protocol-for-8k-video/)

>This makes DVB first standards body of its kind to add a next generation video codec to its media specification.

Well technically it is the Brazilian SBTVD that was the first to select VVC. ( With LCEVC on top ) And DVB aren't just looking at VVC, they seems to be adding AV1 and AVS3 as well.

[rwill]

>This makes DVB first standards body of its kind to add a next generation video codec to its media specification.

Well technically it is the Brazilian SBTVD that was the first to select VVC. ( With LCEVC on top ) And DVB aren't just looking at VVC, they seems to be adding AV1 and AVS3 as well.

I was under the impression that DVB adds every codec to their specs that not really trying hard to avoid that. I mean they had VC-1 and whatnot. What national broadcasters then specify for their respective country they operate in is a completely other matter.

[soresu]

>This makes DVB first standards body of its kind to add a next generation video codec to its media specification.

Well technically it is the Brazilian SBTVD that was the first to select VVC. ( With LCEVC on top ) And DVB aren't just looking at VVC, they seems to be adding AV1 and AVS3 as well.

From what I heard the latest news neglects any mention of AV1 for next gen DVB after that initial flutter of support.

[ksec]

I was under the impression that DVB adds every codec to their specs that not really trying hard to avoid that. I mean they had VC-1 and whatnot. What national broadcasters then specify for their respective country they operate in is a completely other matter.

That is true.

I just want to play with VVC and LCEVC.....

[FranceBB]

From what I heard the latest news neglects any mention of AV1 for next gen DVB after that initial flutter of support.

Yeah, no chance AV1 is gonna be used anywhere other than streaming services and perhaps user mobiles one day when there's gonna be hardware support, but definitely not broadcasting.

[hajj_3]

Tagivan has now added several more patents to the list on: https://www.mpegla.com/wp-content/uploads/VVC-att1.pdf

I wonder whether they bought out patents from another company and moved them over to the mpeg-la patent pool. The number of patents for great britain has increased from 2 to 7.

[benwaggoner]

Why on the web it's deinterlaced to 25p instead of being bob-deinterlaced to 50p? I have no idea, it's another department that performs the consumer encode, but I'm sure they have their reasons (I just don't know them).
I would not assume they have good reasons. This is often due to old systems and configs that haven't been updated for the modern era where all consumer devices can do 60p no problem.

There may be some ancient devices that can do 720p60 and 1080p30, but not 1080p60. If the player heuristics don't have basic level detection and enforcement, maybe some device might get 1080p60 it can't play. But players should have been doing level detection and enforcement for years now.

[birdie]

ACM Mile-High Video conference: Day 2 (https://www.youtube.com/watch?v=oGSXDuNtkiU) - some sad talks about VVC.

VVDec now sports a WASM (C to JS translator) decoder (https://github.com/fraunhoferhhi/vvdec) which can decode video using your CPU in a web browser without using any 3d-party codecs.

There's a demo here (https://vvdec.hhi.fraunhofer.de/demo) as well but it's password protected.

[MoSal]

WASM (C to JS translator)

That's not what WASM is.

[Selur]

WASM = webassemply (https://webassembly.org/)

[birdie]

That's not what WASM is.

It surely is: https://en.wikipedia.org/wiki/WebAssembly

[MoSal]

It surely is: https://en.wikipedia.org/wiki/WebAssembly

WASM is not "a C to JS translator". Neither the source has to be C, nor the target is JS.

[Balling]

It is impossible to translate C to Javascript. Even if not talking about atomics and memory APIs, there is no inline assembly and no intrinciscs used for AVX512 and stuff. Because Javascript has a virtual machine, and thus no access to assembly from code. Moreover its standard library is far from being mature. It cannot even do pow() correctly because it did not port open source C code Microsoft or GMP pow() used in glibc and C library of windows, instead v8 uses some garbage code google take from fdlibm. First link in google https://github.com/WebAssembly/design/issues/1206

[LigH]

New upload: VTM Encoder Version 16.2 [Windows][GCC 12.1.0][64 bit] (https://www.mediafire.com/file/ydfbb9ku6mmjhwb/VTM_16.2_d12cce06.7z/file) d12cce06

[benwaggoner]

New upload: VTM Encoder Version 16.2 [Windows][GCC 12.1.0][64 bit] (https://www.mediafire.com/file/ydfbb9ku6mmjhwb/VTM_16.2_d12cce06.7z/file) d12cce06
Wow, just running it dumps 3732 lines of help text to the console! There is a lot in there.

[LigH]

Apparently this is the "reference software" (development test encoder), not the end user encoder. But that's what MABS compiles. Jamaika uses VVenC in the XEVE package, I believe...

[rwill]

It is impossible to translate C to Javascript. Even if not talking about atomics and memory APIs, there is no inline assembly and no intrinciscs used for AVX512 and stuff. Because Javascript has a virtual machine, and thus no access to assembly from code.

Although I do not want to wake up sleeping dogs I would like to note that WebAssembly had its first SIMD proposal in 2017. So SSE/AVX is quite possible.

[LigH]

media-autobuild suite supports uvg266 now! (https://forum.doom9.org/showthread.php?p=1969974#post1969974)

[LigH]

Apart from VVdeC WASM, are there any other separate and interactive media players know to support VVC yet?
_

bitmovin vvDecPlayer (https://github.com/bitmovin/vvDecPlayer) as source repo. Requires compilation with Qt libs.

MartinEesmaa's VVCEasy (https://github.com/MartinEesmaa/VVCEasy) also looks promising.

[birdie]

@LigH

https://github.com/OpenVVC/FFmpeg

https://github.com/InterDigitalInc/VTMDecoder_VLCPlugin

https://github.com/TencentCloud/O266player

The fact that two years after the finalization of the codec we still have zero free ready to use players sounds to me like the org behind the codec has buried it.

[FranceBB]

The fact that two years after the finalization of the codec we still have zero free ready to use players sounds to me like the org behind the codec has buried it.

Well, never say never, but yeah it is a bit concerning.
I didn't have the chance to look at H.266 VVC for a few months, so I went back to MPV to check whether they added support in the meantime and... nope.

I tried to decode:
Sample 1 - FULL HD 1835 kbps VVC H.266 (https://www.elecard.com/storage/video/Traffic_1920x1080.webm)
Sample 2 - FULL HD 5322 kbps VVC H.266 (https://www.elecard.com/storage/video/Cows_1920x1080.webm)

But I had to use VVDec.
OpenVVC, VTMDec and O266Player probably work too, although I haven't tried them, but still, this is far from being user friendly, so until there are gonna be players that support this properly out of the box, I don't see it getting mass adoption anytime soon.

Speaking of which, OpenVVC integrates the decoder in FFMpeg, so I expected FFMpeg not to support it out of the box, however if I take a normal build of FFMpeg I can clearly see

..V.L. vvc H.266 / VVC (Versatile Video Coding)

Yet if I try with ffplay -i "file.webm" or ffmpeg -i "file.webm" -f null, it can't decode anything, so it looks like the decoder hasn't been merged to the master yet and until then, everything else won't support decoding.

[Jamaika]

The topic should not interest me.
I wonder how much google bought the vvc project and how much is the flow of information from av1 to vvc or vice versa.
So recently I see that some of the creators are in the google team.

OpenVVC failed to compile. It has lot of bugs. There is project not realized vision.

Fraunhoferhhi decoder VVC isn't integrated with ultravideo VVC. At least in my gcc tests.

[LigH]

The VLC decoder plugin by InterDigital Inc. was shipped in VVCEasy and works well for raw streams from uvg266. Next test - multiplexing... MP4Box should be able. Martin Eesmaa mentioned license issues around Exhale and XHE-AAC, so audio will be more conservative.

PS: MP4Box can create an MP4 containing VVC video. But VLC with plugin does not decode the video in it.

[a5180007]

@LigH VLC with plugin plays the vvc m2ts outputs from tsMuxer.

[birdie]

VVC is almost not dead:

https://www.ietf.org/id/draft-ietf-avtcore-rtp-vvc-17.html

[LigH]

New uploads: [Windows][GCC 12.1.0][64 bit]

VTM Encoder/Decoder Version 17.1rc1 (https://www.mediafire.com/file/buws05sy4o6chy7/VTM_17.1rc1_da38667a.7z/file) da38667a

Fraunhofer VVC Encoder ver. 1.5.0 (https://www.mediafire.com/file/ua5zabqlc5p5e7o/vvenc_1.5.0-efea44f.7z/file) efea44f

Fraunhofer VVC Decoder ver. 1.5.0 (https://www.mediafire.com/file/psre1i60jpxolas/vvdec_1.5.0-108d230.7z/file) 108d230

[Tommy Carrot]

Thank you, finally some vvc builds with simd enabled. Jamaika is providing builds for vvc, but his compiles are pure c, around 3-4 times slower.

[birdie]

Live VVC/H.266 UHD Encoder Announced by Spin Digital (https://spin-digital.com/announcements/live-vvc-uhd-encoder/), CPU-based software solution.

[edison]

The VLC decoder plugin by InterDigital Inc. was shipped in VVCEasy and works well for raw streams from uvg266. Next test - multiplexing... MP4Box should be able. Martin Eesmaa mentioned license issues around Exhale and XHE-AAC, so audio will be more conservative.

PS: MP4Box can create an MP4 containing VVC video. But VLC with plugin does not decode the video in it.

I have try the MP4Box (GPAC version 2.0-rev0-g418db414-master, download from https://www.videohelp.com/software/MP4Box), seems not work:

C:\Program Files\GPAC> .\mp4box.exe -add .\VVC.h266 -new d:\h266.mp4
[FFDmx] Fail to open .\VVC.h266 - error Invalid data found when processing input
Filters not connected:
mp4mx (importer:file=000001F4D587BD40) (idx=1)
[Importer] Error importing .\VVC.h266
Failure while importing media: Filter not found for the desired type
Error importing .\VVC.h266: Filter not found for the desired type

[LigH]

The media-autobuild suite compiled already branch v2.1-DEV of MP4Box for me.

[LigH]

New uploads: [Windows][GCC 12.2.0][64 bit]

VTM Encoder/Decoder Version 17.2 (https://www.mediafire.com/file/dvkm3wbujizxate/VTM_17.2_da9773ea.7z/file) da9773ea

Fraunhofer VVC Encoder ver. 1.6.0 (https://www.mediafire.com/file/kkdxnja63o1bnv3/vvenc_1.6.0-364c605.7z/file) 364c605

Fraunhofer VVC Decoder ver. 1.6.0 (https://www.mediafire.com/file/axydv7vf0k77tga/vvdec_1.6.0-01fbc8e.7z/file) 01fbc8e

[olduser217]

Realtek launched set-top box SoC that supports 4k VVC decoding.

https://www.realtek.com/en/press-room/news-releases/item/realtek-launches-world-s-first-4k-uhd-set-top-box-soc-rtd1319d

[ksec]

Realtek launched set-top box SoC that supports 4k VVC decoding.

https://www.realtek.com/en/press-room/news-releases/item/realtek-launches-world-s-first-4k-uhd-set-top-box-soc-rtd1319d

As far as I am aware, all broadcasting companies are moving or plan to move to VVC. RealTek being a large player in this market certainly need to response. Especially its usage in India and China.

[benwaggoner]

As far as I am aware, all broadcasting companies are moving or plan to move to VVC. RealTek being a large player in this market certainly need to response. Especially its usage in India and China.
My sense from IBC is that the broadcast and consumer electronics companies are looking to move adopt VVC over the next few years, just as AVC and HEVC was broadly adopted by those industries around five years after standardization. There's no doubt that VVC is substantially the best available standardized video codec today and for some years to come. VVC+ and AV2 are being worked on, but are at least a few years from standardization, and a few years after that before potential practical deployability. And mobile always fast follows for CE compatibility.

Sustainability was a bit topic at IBC, with a lot of talk about the need to constrain bandwidths to save electricity. So that's an added incentive to adopt newer more efficient compression tech, on top of the other usual reasons.

There wasn't much talk about AV1 at IBC outside of a checklist feature for multi-codec products. LC-EVC got more attention than I'd expected. It's maturing nicely as a technology. I didn't hear any mention of EVC outside of people explaining that LC-EVC isn't related to it.

[birdie]

vvenc 1.6.1 is something to behold, though it's extremely slow.

Tried it with `--preset slower --qp 20` (near perfect detail preservation) and it's really really really good. Beats AV1 by a wide margin.

For a 1080p source that's ... 0.04 fps on my Ryzen 7 5800X.

I used mp4box (master git version) to mux the resulting video.

[ksec]

vvenc 1.6.1 is something to behold, though it's extremely slow.

Tried it with `--preset slower --qp 20` (near perfect detail preservation) and it's really really really good. Beats AV1 by a wide margin.

For a 1080p source that's ... 0.04 fps on my Ryzen 7 5800X.

I used mp4box (master git version) to mux the resulting video.

Any Screencaps ?

[LigH]

New uploads: [Windows][GCC 12.2.0][64 bit]

VTM Encoder/Decoder Version 18.2 (https://www.mediafire.com/file/ds8dy8330utfdg2/VTM_18.2_714f05a7.7z/file) 714f05a7

Fraunhofer VVC Encoder ver. 1.6.1 (https://www.mediafire.com/file/14wxemej2h1rij1/vvenc_1.6.1-8ea0dc5.7z/file) 8ea0dc5

Fraunhofer VVC Decoder ver. 1.6.0 (https://www.mediafire.com/file/dq06dyc7qy1jg8n/vvdec_1.6.0-2c548eb.7z/file) 2c548eb

[andrew.46]

I have created a couple of VVC files with vvencapp under Linux; I have failed however to find an easy way to play these files back under either Windows or Linux. Something I have missed?

[birdie]

I have created a couple of VVC files with vvencapp under Linux; I have failed however to find an easy way to play these files back under either Windows or Linux. Something I have missed?


This (https://forum.doom9.org/showthread.php?p=1970049#post1970049) and this (https://github.com/MartinEesmaa/VVCEasy).

[Gravitator]

Still no response to scene change.

[benwaggoner]

Still no response to scene change.
With VTM or VVCEnc?

[Gravitator]

Привет!
VVCEnc. Is there a way for VLC to play from an mp4 container?

[LigH]

A plugin by InterDigitalInc (https://github.com/InterDigitalInc/VTMDecoder_VLCPlugin) does exist, but to play it out of containers, VLC's splitters need updates (https://code.videolan.org/videolan/vlc/-/issues/27055), and the conversation derailed.

[LigH]

New uploads: [Windows][GCC 12.2.0][64 bit]

VTM Encoder/Decoder Version 19.0rc1 (https://www.mediafire.com/file/9wskhtq5fk4e9y3/VTM_19.0rc1_cf6653dc.7z/file) cf6653dc

Fraunhofer VVC Encoder ver. 1.6.1 (https://www.mediafire.com/file/b9eug58oimoiyv9/vvenc_1.6.1-34d3898.7z/file) 34d3898

Fraunhofer VVC Decoder ver. 1.6.0 (https://www.mediafire.com/file/zbp8ei1alwpchhc/vvdec_1.6.0-6494d7a.7z/file) 6494d7a

[Jamaika]

Changes I take no responsibility for. Why LigH codecs have SIMD AVX2.
//#if defined( __MINGW32__ ) && !defined( __MINGW64__ )
//# define SIMD_UP_TO_SSE42 0
//#else
# undef SIMD_UP_TO_SSE42
//#endif
Very interesting.
//# ifndef _WIN32
// don't detect AVX, as there are problems with MSVC production illegal ops for AVX
ext = AVX;
//# endif
When using AVX512 we need to add USE_AVX2.
# ifdef USE_AVX2
doCpuidex( regs, 7, 0 );
if( !( regs[1] & BIT_HAS_AVX2 ) )
return ext;
ext = AVX2;
# endif
vvencapp: Fraunhofer VVC Encoder ver. 1.6.1-c5da1b5 [Windows][GCC 11.3.1][64 bit][SIMD=AVX]
https://www.sendspace.com/file/xhydxt
XEVE: eXtra-fast Essential Video Encoder ver. 0.4.2-a7425e3
https://www.sendspace.com/file/ic1vv7

[LigH]

Well, I simply used the media-autobuild suite, which uses MSYS2 + MinGW by default (in case of VVC apps, only MinGW64), and GnuCC 12.2 (could use Clang alternatively).

I am no developer. I am happy when the suite passes, and try educated guesses to make it work with the help of more educated people when something fails.

[hajj_3]

Patent pool update: Access Advance has now published a list of their patents. The access advance patent list shows the expiry date of each patent and whether it is for decoding or encoding, which is nice :)

MPEG-LA patents: https://www.mpegla.com/wp-content/uploads/VVC-att1.pdf
Access Advance patents: https://accessadvance.com/wp-content/uploads/2022/11/2022.11.01-VVC-Website-Patent-List.xlsx

Total patents for MPEG-LA + Access Advance for the following countries:

UK: 16 + 25 = 41
USA: 36 + 314 = 350

MPEG-LA licensors (patent owners), total number: 12:

b<>com
British Broadcasting Corporation
Digital Insights Inc.
FG Innovation Company Limited
Fujitsu Limited
Hanwha Techwin Co., Ltd.
Koninklijke KPN N.V.
Nippon Hoso Kyokai
Orange
Siemens Corp.
Tagivan II LLC
Vidyo, Inc.

Access Advance licensors (patent owners), total number: 34:

Alibaba Singapore Holding Private Limited
B1 Institute of Image Technology, INC.
Chips&Media, Inc.
CommScope Technologies LLC
Dolby Laboratories Licensing Corporation (Affiliate of Dolby Laboratories, Inc.)
Dolby International AB (Affiliate of Dolby Laboratories, Inc.)
Electronics and Telecommunications Research Institute
Fujitsu Limited
GE Video Compression, LLC (Affiliate of General Electric Company)
Godo Kaisha IP Bridge 1
HFI Innovation Inc. (Affiliate of MediaTek, Inc.)
IDEAHUB Inc.
Industry-Academy Cooperation Foundation of Sejong University
Intellectual Discovery Co., Ltd.
IUCF-HYU (Industry-University Cooperation Foundation Hanyang University)
JVCKENWOOD Corporation
KDDI Corporation
Koninklijke Philips N.V.
Korea Advanced Institute of Science & Technology
Korean Broadcasting System
Kuaishou Technology
Kwangwoon University, Industry-Academic Collaboration Foundation
Mitsubishi Electric Corporation
NEC Corporation
OP Solutions, LLC
Panasonic Holdings Corporation
Sisvel International S.A.
SK Telecom Co., Ltd.
Sun Patent Trust
Sungkyunkwan University (SKKU) Research & Business Foundation
SZ DJI Technology Co., Ltd.
Toshiba Corporation
University-Industry Cooperation Group of Kyung Hee University
XRIS Corporation

Interestingly Sisvel (the patent pool company) is on the list of access advance patent owners.

[ksec]

Interestingly Sisvel (the patent pool company) is on the list of access advance patent owners.

Throughout these years the Group has worked closely with over 25 patent owners, including:

3M; British Broadcasting Corporation (BBC); DTVG Licensing (a subsidiary of DIRECTV); Electronics and Telecommunications Research Institute (ETRI); France Telecom/Orange; Fraunhofer IIS; Hewlett Packard; LG Electronics; Motorola; Nippon Telegraph and Telephone Corporation; NTT DOCOMO; Nokia; Panasonic; Radiotelevisione Italiana (RAI); Royal KPN; Royal Philips; Samsung; Siemens; SIDSA; SK Telecom; TB Invent; TDF; Telecom Bretagne; Telecom Italia; ThingMagic; Victor Company of Japan (JVC) and Zebra Technologies.

[ksec]

https://www.rapidtvnews.com/2022120763207/v-nova-globo-kick-off-lcevc-experimental-broadcast-for-world-cup.html

The showcase also features the first end-to-end trial over DASH streaming of an LCEVC-enhanced VVC video, as an example of the capabilities that are developing to support the upcoming TV 3.0 standard, Brazil’s next-generation DTT system that is being specified by the Brazilian SBTVD Forum and is due to be deployed in 2025. It is the first time these technologies are being used in a complete end-to-end production to provide 4K HDR video with immersive and personalised audio. The system will facilitate the distribution of current and future formats, including 8K resolution, HDR and Next-Generation Audio (NGA) to over-the-air broadcast (OTA) and over-the-top (OTT) streaming platforms.

The LCEVC live showcase is running during the FIFA World Cup Qatar 2022 from 20 November to 18 December 2022.

[hajj_3]

https://www.rapidtvnews.com/2022120763207/v-nova-globo-kick-off-lcevc-experimental-broadcast-for-world-cup.html

I guess that hardware decoders for vvc ecm (h.267) won't be ready for 2025 so lcevc + vvc makes sense.

[benwaggoner]

I guess that hardware decoders for vvc ecm (h.267) won't be ready for 2025 so lcevc + vvc makes sense.
Do you think LC-EVC + H.267 wouldn't make sense? I've not been following the ECM work in detail yet.

[ksec]

Do you think LC-EVC + H.267 wouldn't make sense? I've not been following the ECM work in detail yet.

At the moment ECM is basically further improved VTM + a somewhat different take of LC-EVC.

[asarian]

vvenc 1.6.1 is something to behold, though it's extremely slow.

Tried it with `--preset slower --qp 20` (near perfect detail preservation) and it's really really really good. Beats AV1 by a wide margin.

Are there pre-built Windows binaries for it yet? I'd love to use it. :)

[Boulder]

Are there pre-built Windows binaries for it yet? I'd love to use it. :)

I suppose you can use Media-autobuild Suite to compile a binary (along with many others) if none are readily available.
https://github.com/m-ab-s/media-autobuild_suite

[asarian]

:thanks:

[LigH]

New uploads: [Windows][GCC 12.2.0][64 bit]

VTM Encoder/Decoder Version 19.0rc1 (https://www.mediafire.com/file/9wskhtq5fk4e9y3/VTM_19.0rc1_cf6653dc.7z/file) cf6653dc

Fraunhofer VVC Encoder ver. 1.6.1 (https://www.mediafire.com/file/b9eug58oimoiyv9/vvenc_1.6.1-34d3898.7z/file) 34d3898

Fraunhofer VVC Decoder ver. 1.6.0 (https://www.mediafire.com/file/zbp8ei1alwpchhc/vvdec_1.6.0-6494d7a.7z/file) 6494d7a

You should read back more before asking for already existing things :p

[ksec]

NHK Highlight VVC Advances for 8K

https://8kassociation.com/industry-info/8k-news/nhk-highlight-vvc-advances-for-8k/

[benwaggoner]

NHK Highlight VVC Advances for 8K

https://8kassociation.com/industry-info/8k-news/nhk-highlight-vvc-advances-for-8k/
Spatial enhancement layers have been around forever, and are commonly used in videoconferencing. They've rarely been used in VOD or broadcast, as the overhead of the layers has been significant. The total bits required to get the top layer can easily be 10-20% more than if the top resolution had been encoded directly. I've not dived deeply into VVC's scalable implementation to see if they've made the layering overhead smaller, which could help.

An 8K top layer, or even a 4K, can be quite low with content that doesn't have that much detail in the first place, as the upscaled lower resolution can look pretty much the same. For lots of content, 2160p and 1080p don't look that different, and for moving image viewing distances it's hard to find examples where >2160p has discernible additional detail outside of carefully constructed A/B comparisons. Particularly not with classic 24p with 1/48th sec shutter speed as motion blur will eradicate any theoretical extra detail with even very slight motion.

The LC-EVC approach is interesting as well, being metadata driven with much lower overhead than a whole spatial enhancement layer.

[sonnati]

The LC-EVC approach is interesting as well, being metadata driven with much lower overhead than a whole spatial enhancement layer.

I'm not sure LC-EVC is metadata driven. Outside some frame level params and a parametric synthetic grain generator there's an actual enhancement layer (with very simple time prediction).

[birdie]

A new series of patches (https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=7922) to add VVC support in FFMpeg has been published. They use vvdec/vvenc libraries for decoding/encoding. Authored by Thomas Siedel (https://spin-digital.com/wp-content/uploads/2018/04/spin-digital-022w.jpg) from Spin Digital. They are compatible with FFMpeg 5.1.2. I'll test them ASAP. Finally something worth testing. Found them accidentally using Google.

[ksec]

A new series of patches (https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=7922) to add VVC support in FFMpeg has been published. They use vvdec/vvenc libraries for decoding/encoding. Authored by Thomas Siedel (https://spin-digital.com/wp-content/uploads/2018/04/spin-digital-022w.jpg) from Spin Digital. They are compatible with FFMpeg 5.1.2. I'll test them ASAP. Finally something worth testing. Found them accidentally using Google.

I was surprised considering their previous stand on AV1 only. Turns out this is on patchwork and not on official FFmpeg 5.2 Dev.

[birdie]

I was surprised considering their previous stand on AV1 only. Turns out this is on patchwork and not on official FFmpeg 5.2 Dev.

Yep, they are just published, not yet merged.

AFAIK FFMpeg developers don't oppose them, they just need well written code which will be properly maintained.

[ksec]

Yep, they are just published, not yet merged.

AFAIK FFMpeg developers don't oppose them, they just need well written code which will be properly maintained.

I am not sure if it is officially official. But I remember a few members of FFmpeg have on multiple occasions said they do not intend to include VVC into mainline work given how some of them are working on AV1 and are committing to AV1.

There were VVC related work submitted in 2020 already. And AFAIK none of them have been included.

[birdie]

I am not sure if it is officially official. But I remember a few members of FFmpeg have on multiple occasions said they do not intend to include VVC into mainline work given how some of them are working on AV1 and are committing to AV1.

I've never heard anyone say or imply that. Citations needed.

There were VVC related work submitted in 2020 already. And AFAIK none of them have been included.

And it was merged (https://git.ffmpeg.org/gitweb/ffmpeg.git?a=search&h=HEAD&st=commit&s=VVC), no prob.

[birdie]

The above patches build with the current FFMpeg git snapshot (they are not compatible with version 5.1.2) and you can watch VVC encoded videos just fine.

https://i.ibb.co/dMj6Q0L/Screenshot-2022-12-27.webp

[ksec]

An interesting comparison between CPU and Hardware H.264 / H.265 and AV1 Encoding.

https://rigaya.github.io/vq_results/

[birdie]

An interesting comparison between CPU and Hardware H.264 / H.265 and AV1 Encoding.

https://rigaya.github.io/vq_results/

This is a topic about VVC.

[ksec]

I've never heard anyone say or imply that. Citations needed.



And it was merged (https://git.ffmpeg.org/gitweb/ffmpeg.git?a=search&h=HEAD&st=commit&s=VVC), no prob.

Apart from Nuo Mi's commit, all the other VVC has nothing to do with H.267 itself but Dolby Vision Configuration Box aka 'dvvC'.

But I do remember it was a question from Nuo Mi on integration with VVC and FFmpeg. So I will probably look it up later.


Edit: https://patchwork.ffmpeg.org/project/ffmpeg/patch/20201221060710.12230-6-nuomi2021@gmail.com/#60590

Lynne Dec. 22, 2020, 4:10 p.m. UTC | #4
Dec 21, 2020, 07:07 by nuomi2021@gmail.com:

> you can download test clips here:
> https://www.itu.int/wftp3/av-arch/jvet-site/bitstream_exchange/VVC/under_test/VTM-11.0/
>

Honestly, I'm not sure about this patch. Its an external library decoder, which
doesn't help us very much, and its for a codec competing with another codec
(AV1) for which we don't really have a native decoder for yet. Not to mention
some of us were involved with the effort to standardize and/or write a decoder
for AV1, so there's also a personal element to not wanting VVC to have any
success.

So I'm kind of against this particular patch as-is. I'd be okay with it being a native
decoder built into our codebase. But as-is, this serves nothing to help the
project, but only corporations who invested into the codec and want to see
some return on their investment from enforcing licensing on our users.
And no one is even really using this codec at the moment.



Nuo Mi Dec. 22, 2020, 5:02 p.m. UTC | #5
Hi Lynne,
Thanks for the comments.
We only have a small patch for the vvdec wrapper. All other codes (raw
demuxer, cbs reader, parser, and cbs writer in the future) will benefit the
native decoder and the vvc ecosystem.

I do not think av1 is the savior. No matter how it promised you, if we only
have one codec to choose from, it will be a disaster for all of us.
But, if you and the ffmpeg tech committee decided to reject all vvc patches
in the future, I can accept it and stop work on this.

BTW, do you know the detailed plan for av1 native decoder? will we port
dav1d back or implement a new one?

thanks

[FranceBB]

Not to mention
some of us were involved with the effort to standardize and/or write a decoder
for AV1, so there's also a personal element to not wanting VVC to have any
success.


this was a personal opinion which would be fine, however this:


So I'm kind of against this particular patch as-is.


is not.
I do understand people working on AV1 and such, but coming to the point of blocking an H.266 VVC decoding patch is too much. We should really be able to easily decode any codec, no matter what. With this logic, we would have never had reverse engineered decoders for codecs like DNxHR and Apple ProRes for video or indeed DolbyE and DolbyED2 for audio. Sure, one could make a reasoning on why he might want to see one codec succeed and another one fail, but not having the decoding isn't gonna help anyone, if anything it's gonna make things worse!

Think about DolbyE for instance.
You might want to say "Ah, FLAC should succeed so I'm not gonna add decoding".
Will corporations move to FLAC? Nope, they will just buy software decoders like DolbyDP600 and potentially make things worse as it would feed money straight to Dolby.
The same applies to video codecs, not having a video decoder for Apple ProRes would lead to people giving money to Apple 'cause they wouldn't be able to refuse such a masterfile, same thing for DNxHR with AVID and the same thing with MPEG-LA for H.266 VVC.

In a nutshell, I'm glad that nowadays Libav can decode pretty much anything (including proprietary codecs) and I really wouldn't want to see it stopping right now 'cause it would only make things harder for those who use those in professional settings like the various broadcasters.




I do not think av1 is the savior. No matter how it promised you, if we only
have one codec to choose from, it will be a disaster for all of us.


This is exactly right and I think exactly the same.



But, if you and the ffmpeg tech committee decided to reject all vvc patches
in the future, I can accept it and stop work on this.


This is even more dangerous.
We had 1 good guy working on the VVDec integration and they're making him go away and stop working on it, potentially. I mean, honestly, I really hope the people in the FFMpeg committee change their mind 'cause right now this way of thinking it's really not good and it's not gonna happen.
I mean, we can all be proud and thankful to google for what it has done with AV1 and everything, but we shouldn't really limit decoding to just open codecs 'cause it would mean the END of the open source tools in professional settings.

[nevcairiel]

Note that the main complaint is not against VVC in general, and such a complaint would never be able to stand anyway, but rather the patch merely being a thin wrapper around an external decoding library controlled by a corporation, rather then actual efforts to bring open and native decoding to FFmpeg.
If someone were to develop a native decoder for FFmpeg, and not an external library, none of these arguments would even exist. All these other proprietary codecs you mention have native decoders in FFmpeg.

I would recommend those "professional" users deriving revenue from FFmpeg to chip in and further such a project. FFmpeg does not make money, but developers need to eat.

PS:
The argument against "wrappers" is that they don't really further the open-source multimedia ecosystem. Even decoders benefit from competition, which is why dav1d was created by a group of ffmpeg developers (and others), instead of just using aom.

[Wiabol]

A decoder developed by a corporation. Bold opinion for a bunch of Google fanboys.

VVC, just as AV1 are becoming too complex to be integrated into the main codebase. That's why there's David.

[birdie]

Note that the main complaint is not against VVC in general, and such a complaint would never be able to stand anyway, but rather the patch merely being a thin wrapper around an external decoding library controlled by a corporation, rather then actual efforts to bring open and native decoding to FFmpeg.
If someone were to develop a native decoder for FFmpeg, and not an external library, none of these arguments would even exist. All these other proprietary codecs you mention have native decoders in FFmpeg.

I would recommend those "professional" users deriving revenue from FFmpeg to chip in and further such a project. FFmpeg does not make money, but developers need to eat.

PS:
The argument against "wrappers" is that they don't really further the open-source multimedia ecosystem. Even decoders benefit from competition, which is why dav1d was created by a group of ffmpeg developers (and others), instead of just using aom.

Tons of codecs are supported exactly this way in FFMpeg - by using "thin" wrappers for external libraries.

This includes AV1 as well.

[rwill]

The argument against "wrappers" is that they don't really further the open-source multimedia ecosystem. Even decoders benefit from competition, which is why dav1d was created by a group of ffmpeg developers (and others), instead of just using aom.

But this "argument" can easily be debunked.

VVdeC is under 3-clause BSD. IT hardly can be more open source than that. By that "argument"s logic x265 should be removed too as it is integrated with a wrapper and developed by a corporation.

[birdie]

I've just talked to FFMpeg developers in their IRC channel.

No one opposes VVC, it's just no one is currently interested in it, thus no one wants to review the patches to merge them. There are no other reasons. As simple as that.

At least yesterday's FFMpeg GIT snapshot works fine with them, so there's that.

I'm pretty sure if companies behind VVC actually cared, they'd sponsor someone to get this code merged. Darn.

[nevcairiel]

But this "argument" can easily be debunked.

VVdeC is under 3-clause BSD. IT hardly can be more open source than that.

No where did I mention the license. Everyone relying on the exact same codebase to do decoding also doesn't debunk the competition I mentioned.

By that "argument"s logic x265 should be removed too as it is integrated with a wrapper and developed by a corporation.

We are talking about decoders here. Encoding is a very different task, and a much more complex thing to implement (well).

--

At the end of the day, no format is being blocked based on it being disliked or in competition to anyones favorite format. People may express that sentiment, as is their right, but it will not be taken into account by other developers to decide if its suitable for merging. The main reason something doesn't get merged is either one of two things - patchset needs work, and/or no developer is available (or interested) in dealing with it.

[rwill]

No where did I mention the license. Everyone relying on the exact same codebase to do decoding also doesn't debunk the competition I mentioned.


Yes, you did not mention the license, you did mention the "open-source multimedia ecosystem" though. And one wrapped decoder is better than none.



We are talking about decoders here. Encoding is a very different task, and a much more complex thing to implement (well).


Well decoding seems to be a complex thing too because last time I checked the FFmpeg H.262 and H.264 decoders failed in decoding conformance streams correctly.

HEVC support is much better but they are "wrapping" OpenHEVC there?

[nevcairiel]

OpenHEVC was/is a fork of libavcodec, which then got re-integrated into ffmpeg eventually. It does not require any external dependencies to work.

[FranceBB]

I would recommend those "professional" users deriving revenue from FFmpeg to chip in and further such a project. FFmpeg does not make money, but developers need to eat.


Not FFMpeg but open source in general and believe me, they do. Think about AVC Intra classes in x264, if it wasn't for NRK funding the development, we wouldn't have those.
Same goes for DolbyE and DolbyED2 decoders written by Nicolas Gaullier who works for a French broadcasting company, Sky/Comcast funding x265 development with Multicoreware and I could go on, but there are lots of TVs helping out as they can in open source development. Even me, in my little, I try to contribute as much as I can to the community.


I'm pretty sure if companies behind VVC actually cared, they'd sponsor someone to get this code merged. Darn.

Easier said than done.
I'm still trying to get the code for the DolbyED2 Atmos decoder merged to the main FFMpeg codebase and I begged the mailing list to no avail.
If someone has the power to merge, please merge: https://trac.ffmpeg.org/ticket/9864

[MartinEesmaa]

I updated libvvenc codes for new vvenc patch:
https://github.com/MartinEesmaa/FFmpeg-FixVVC/commit/6622bf8e566a7656bbae306d336f2f89c3462381

Original patches:
https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=7922

Builds of latest FFmpeg VVCEasy:
https://github.com/MartinEesmaa/VVCEasy/blob/master/FFMPEGVVC.md#ffmpeg-downloads-xhe-aac--vvc-endecoder-plugin-compiled-by-martin-eesmaa

- Martin Eesmaa

[birdie]

A patch series to support VVC encoding/decoding in ffmpeg via vvenc/vvdec has again been resubmitted (https://patchwork.ffmpeg.org/project/ffmpeg/cover/20230103134040.41140-1-thomas.ff@spin-digital.com/). There are minor fixes here and there:

This patch set adds H266/VVC support.
This includes parsing, muxing, demuxing, decoding and encoding.
Decoding is done using the external library VVdeC
(https://github.com/fraunhoferhhi/vvdec.git) and can be enabled with
--enable-libvvdec.
Encoding is done using the external library VVenC
(https://github.com/fraunhoferhhi/vvenc.git) and can be enabled with
--enable-libvvenc.

Changes since v4:

General:
- Add original author to patches 01-03
- Add co-author to patches 04 and 05

PATCH 02/10 configure / cbs_h266_syntax_template
- bugfix: add cbs_h266, cbs_h266_select (moved from patch 03/10)
- bugfix: parsing multilayer in cbs_h265_syntax_template

PATCH 03/10 libavcodec/vvc_parser.c
- bugfix: check startcode length (3 or 4 byte) to
find correct frame end position

PATCH 06/10 libavformat/movenc.c
- merge movenc.c with upstream

PATCH 07/10 libavcodec/libvvdec.c
- bugfix: set correct avframe pts for decoded picture
- bugfix: print additional info if decoding fails

Nuo Mi (3):
avcodec: add enum types for H266/VVC
avcodec: add cbs for H266/VVC
avcodec: add bitstream parser for H266/VVC

Thomas Siedel (7):
avcodec: add MP4 to annexb support for H266/VVC
avformat: add demuxer and probe support for H266/VVC
avformat: add muxer support for H266/VVC
avcodec: add external decoder libvvdec for H266/VVC
avcodec: add external encoder libvvenc for H266/VVC
avformat: add ts stream types for H266/VVC
avcodec: increase minor version for H266/VVC

[FranceBB]

Yep.
Looks like Thomas Siedel from Spin Digital is trying again to get it approved and merged to master and at this point I really hope it is.

[FranceBB]

Hey guys,
there's gonna be a webinar with the multicoreware guys about x266, at what point the project is etc.
I strongly encourage everyone to participate.

https://us02web.zoom.us/webinar/register/WN_P1yr85_ZSDKIvWPmw2jUxw

It's gonna be January 31st at 5PM UK Time.

[Jamaika]

Decoder VVC
https://github.com/ffvvc/FFmpeg

[Jamaika]

VVCSoftware_VTM 19.2-06a9a140
https://www.sendspace.com/file/jmqw85

[birdie]

I've discovered a large library of uncompressed 4K videos under the Creative Commons Attribution 4.0 International License from the European Space Observatory. You can get them here (https://www.eso.org/public/videos/). Will try to compress them visually losslessly using x264, x265 and VVENC and see who wins.

The codec used is hqx (https://wwwapps.grassvalley.com/docs/WhitePapers/professional/GV-4097M_HQX_Whitepaper.pdf) (CHQX (https://codecs.multimedia.cx/2013/05/final-words-on-canopus-hq-hqa-and-hqx/) / 0x58514843), yuv422p16le(10 bpc) - no idea what it is, but it must be uncompressed (https://www.videohelp.com/software/Grass-Valley-HQX-Codec).

Grass Valley HQX, as an intermediate codec, is specifically designed for editing and post-production: Can withstand re-encoding without significant quality loss. Is built for high speed and low-CPU usage. Allows accurate inter-frame cuts (not grouped around keyframes). Has well-defined chroma characteristics. It is available for both Windows and Macintosh platforms, handles many different video resolutions up to and including 8K (DCI), incorporates an alpha channel for graphics handling, and is available in 8-bit and 10-bit versions. The Grass Valley Codec Pack includes/allows you to import and export video files that use the Grass Valley HQ, Grass Valley HQX, Grass Valley Lossless, and Grass Valley DV codecs.

[FranceBB]

The codec used is hqx (https://wwwapps.grassvalley.com/docs/WhitePapers/professional/GV-4097M_HQX_Whitepaper.pdf) (CHQX (https://codecs.multimedia.cx/2013/05/final-words-on-canopus-hq-hqa-and-hqx/) / 0x58514843), yuv422p16le(10 bpc) - no idea what it is, but it must be uncompressed (https://www.videohelp.com/software/Grass-Valley-HQX-Codec).

Nope.
The GV codec has three profiles: HQ, HQX, Lossless.
In this case they used the HQX profile which is lossy, so it's not lossless nor uncompressed, it's compressed and lossy.
It's a very good mezzanine file, though, generally used for those who need to edit or indeed store it as TX Master for playout in Grass Valley based systems. It's basically the Grass Valley's rival of AVID's DNxHR.

[birdie]

Nope.
The GV codec has three profiles: HQ, HQX, Lossless.
In this case they used the HQX profile which is lossy, so it's not lossless nor uncompressed, it's compressed and lossy.
It's a very good mezzanine file, though, generally used for those who need to edit or indeed store it as TX Master for playout in Grass Valley based systems. It's basically the Grass Valley's rival of AVID's DNxHR.

I've not noticed any perceivable compression artifacts, the bitrate is outright insane, for the file that I downloaded, it's 1 332 878 kb/s, which surely looks like compression, if there is any, is minimal.

4K Bluray has around 75Mbps bitrate - files from the observatory are ~ 18 times denser.

[FranceBB]

I've not noticed any perceivable compression artifacts, the bitrate is outright insane, for the file that I downloaded, it's 1 332 878 kb/s, which surely looks like compression, if there is any, is minimal.

4K Bluray has around 75Mbps bitrate - files from the observatory are ~ 18 times denser.

Yeah, they're called mezzanine files. It's what professional broadcast studios use internally.
For instance, you might have Grass Valley playout ports that play such a file and then output a signal via SDI. Such a signal is then received by an hardware encoder which encodes it as either MPEG-2 for SD channels, H.264 for HD/FULL HD channels and H.265 for UHD channels at consumer tier bitrates, generally around 2.5 Mbit/s for MPEG-2, 12 Mbit/s for H.264 FHD and 25 Mbit/s for H.265 UHD.
Internally, though, it's really not uncommon to see those kind of mezzanine files used and stored/archived.
Keep in mind that what users see is not what studios archive.
As I said, AVID systems use DNxHR, which is quite similar and can reach similar bitrates.

[Asmodian]

The codec used is hqx (https://wwwapps.grassvalley.com/docs/WhitePapers/professional/GV-4097M_HQX_Whitepaper.pdf) (CHQX (https://codecs.multimedia.cx/2013/05/final-words-on-canopus-hq-hqa-and-hqx/) / 0x58514843), yuv422p16le(10 bpc) - no idea what it is, but it must be uncompressed (https://www.videohelp.com/software/Grass-Valley-HQX-Codec).

Uncompressed 3840x2160 10 bpc @ 25 fps is 6220800 kbps (10 x 3 x 3840 x 2160 x 25). 1332878 kb/s is 4.67 times smaller. A very light compression ratio for video, but still compressed. ;)

[benwaggoner]

Uncompressed 3840x2160 10 bpc @ 25 fps is 6220800 kbps (10 x 3 x 3840 x 2160 x 25). 1332878 kb/s is 4.67 times smaller. A very light compression ratio for video, but still compressed. ;)
Yeah, lossless compressed HEVC is only 2-3x larger. We have a ton of peer-reviewed data about mezzanine codecs not impacting final video quality visibly after dozens of generations of reencodes.

[birdie]

The biggest takeaway from today's MulticoreWare x266 webinar: the codec has actively been developed, it's not ready yet, version 1.0 will be released as open source in the second half of this year. The webinar will be published later.

The codec is developed from scratch, i.e. code from VVenc and the VTM reference coder is not used but consulted with.

ffmpeg integration is absolutely planned.

A lot more was said and shared but I wasn't paying enough attention.

[FranceBB]

A lot more was said and shared but I wasn't paying enough attention.

I'll share the slide later

[benwaggoner]

I'll share the slides later
Looking forward to them!

[FranceBB]

It's still early stages, but x266 is currently 13.3 times faster than VTM15 using the same input sources (tested with both FULL HD and UHD materials) and settings thanks to the manually written asm, however it requires about 5% more bitrate. This is with lossy encoding, however it will also support lossless encoding. It's not open source yet but it will supposedly be in Q2 2023 although there's no official date just yet. Once it will, it will take a bit more time to implement a few more stuff 'till version 2.0, then the ffmpeg implementation will probably happen. Down the line GPU acceleration will also be something that will be looked into, however it won't be OpenCL lookahead like we had in x264, but something new entirely and probably CUDA based but it's really too early to tell.
This is the exciting official roadmap (in green it's what has already been done):

https://i.imgur.com/HMCUo0A.png

I'm surprised not to see you at the zoom meeting, Ben.
I would share the slides from the meeting but I just noticed that it says "confidential - limited distribution", so I guess you'll have to wait for the multicoreware guys themselves to upload them.

[birdie]

I would share the slides from the meeting but I just noticed that it says "confidential - limited distribution", so I guess you'll have to wait for the multicoreware guys themselves to upload them.

Weirdly they never mentioned whether the webinar was public or under some sort of NDA. Considering they repeated multiple times that they would release it publicly, I guess there's nothing confidential about it.

[poisondeathray]

Down the line GPU acceleration will also be something that will be looked into, however it won't be OpenCL lookahead like we had in x264, but something new entirely and probably CUDA based but it's really too early to tell.

probably CUDA? Was that mentioned in the presentation or other slides?

Green team would be happy, but I doubt AMD / Intel / ARM/ Apple/ everyone else / would be happy

Thanks for the info & progress update

[FranceBB]

probably CUDA? Was that mentioned in the presentation or other slides?


No mention of CUDA in the slides, just a very vague "GPU hardware acceleration" as things that will be looked into, so I asked the question myself on whether it will be OpenCL or other open initiatives or CUDA.
They said that it's still really far too early to tell, v1.0 is barely there and a lot of coding tools + CPU Assembly optimizations need to be added before we'll even start to talk about that, however they said that given that NVIDIA has some nice things they can leverage on, they MIGHT consider CUDA.




Thanks for the info & progress update

No problem, it's something I care about and I really look forward to gets my hands dirty and make some real comparisons myself as soon as the first build is out.

[benwaggoner]

II'm surprised not to see you at the zoom meeting, Ben.

My scope is really anything between lens to cornea and mic to eardrum these days, so I'm always terribly neglecting two things whenever I'm paying attention to one ;).

[DTL]

No mention of CUDA in the slides, just a very vague "GPU hardware acceleration" as things that will be looked into, so I asked the question myself on whether it will be OpenCL or other open initiatives

As from some version of Microsoft DX12 at the beginning of 202x the motion estimation data from hardware MPEG encoder ASIC is now available as operation system API service (AMD/NVIDIA and in some time Intel accelerators independent) I hope the designers of MPEG codecs may finally start to use it. At least as some starting point of motion estimation with possible onCPU refinement. Though even in its initial release ME API have full mature precision of 1/4 pel. The progress may be with quality of motion vectors in the future ASIC releases (more correct MVs with naturally noised sources and many-frame analysis instead of current 2-frames only).

[birdie]

FOSDEM 2023 VVEnc/VVDec presentation:

https://www.phoronix.com/news/Open-Source-VVC-H266

[birdie]

A patch series to support vvdec in ffmpeg has been submitted (https://patchwork.ffmpeg.org/project/ffmpeg/patch/20230210174106.44514-2-thomas.ff@spin-digital.com/) for the third time.

[FranceBB]

A patch series to support vvdec in ffmpeg has been submitted (https://patchwork.ffmpeg.org/project/ffmpeg/patch/20230210174106.44514-2-thomas.ff@spin-digital.com/) for the third time.

And knowing the AV1 fanboys in the ffmpeg community, it will probably be rejected again, although I sincerely hope that it won't. I even tried to reach out to them everywhere before, but I couldn't convince them...

[birdie]

And knowing the AV1 fanboys in the ffmpeg community, it will probably be rejected again, although I sincerely hope that it won't. I even tried to reach out to them everywhere before, but I couldn't convince them...

They [ffmpeg project] don't have the manpower to review the patches. That's the only reason they've not been merged. They have not been rejected.

I want to compile the upcoming FFMPeg 6.0 release with these patches and start experimenting with VVC a lot more. I love the codec ;-)

[quietvoid]

I'm not sure but I think the reason is mostly that a native decoder in FFmpeg is preferable, and it is already an ongoing project.
So there isn't much point to adding vvdec, at least IMO.

[nevcairiel]

And knowing the AV1 fanboys in the ffmpeg community, it will probably be rejected again, although I sincerely hope that it won't. I even tried to reach out to them everywhere before, but I couldn't convince them...

You really have no clue what you are talking about.

None of these patches were ever actually "rejected" at all, having a large patch set go through various iterations is entirely normal part of development, as reviews point out problems and improvements. This is just how the development process works. Large patchsets rarely get merged on the first try, even less so if they are from external contributors or companies, since those don't necessarily know all the details to make it work perfectly without review. It may be going slow as review bandwidth is limited, but there certainly was no rejection, and just the normal development process going on.

And as pointed out above, a native VVC decoder for ffmpeg is actually in development as well, independent of vvdec or other external libraries.

Contrary to some other projects, development of new features does not happen inside the main ffmpeg tree. So unfinished/in-progress things don't just get merged unless they are considered "finished", at least to a degree of being usable and not making future changes harder.

[birdie]

I'm not sure but I think the reason is mostly that a native decoder in FFmpeg is preferable, and it is already an ongoing project.
So there isn't much point to adding vvdec, at least IMO.

FFMpeg developers themselves are not aware of this development. No idea where you got this information from.

I've not seen a single development tree/tag/branch with anything VVC decoding related either.

[nevcairiel]

FFMpeg developers themselves are not aware of this development. No idea where you got this information from.

I've not seen a single development tree/tag/branch with anything VVC decoding related either.

Not sure what "FFmpeg developers" you are talking to, but if they were of the active kind, they surely would have noticed this project on the mailing list.

The development tree is here:
https://github.com/ffvvc/FFmpeg

Its still quite under development and not finished yet, but should be somewhat usable.

There is also a GSoC 2023 project (https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2023#AssemblycodeforVVCdecoder) listed to enlist a student to help with writing Assembly for it, as well as a general task to get involved with work on it, if you need any more "evidence" that its a real thing endorsed by the FFmpeg project itself.

[FranceBB]

Perhaps, Nevicarel, but from my own experience of ffmpeg contributions, they're left hanging there and not merged without any real explanation on why. Just to name one, I've been waiting for them to merge this for 6 months now and no one replied to my emails and in the ticket there's only someone who uses the nickname Elon Musk (almost definitely not the *real* Elon Musk) which says "No" without providing any details. https://trac.ffmpeg.org/ticket/9864
Nicolas already asked too and yet, nothing.
This led us to actually include the patch ourselves and compile a custom version of FFMpeg, thus running a completely separate version from the rest of the world, which isn't nice of course.
And by the way, yes, we're running that very custom version in production 24/7.
What does that patch do?
It allows DolbyED2 5.1.4 decoding and fixes a decoding error in DolbyE 5.1 in which the decoded audio was slightly shorter than it should have been.
Why they refused it? Dunno.

comment: by Francesco Bucciantini
So... any chance of any of the patches being merged to master anytime soon?

comment by Elon Musk
Nope

Here I've also been blatantly ignored:


comment: by Francesco Bucciantini
Hi everyone,
happy new year.
As you can see this pull request has been stagnating for the last 6 months, forcing us at Sky to build our own FFMpeg with the patch applied.
We've been trying to contact the current maintainer via email on different occasions, but we never had an a reply.
Is there any other maintainer we can talk to?
Thank you in advance,
Frank

so I've now lost faith... :(
My comment might have seemed a bit unfair at a first glance and if I upset someone, I apologize, but believe me, this is a bit frustrating for us as well 'cause I always get nice feedback and collaboration from everyone here on Doom9, especially in the Avisynth community, so when I went to ask a bunch of stuff to the FFMpeg community I thought it was gonna be the same, but apparently it's not...
If you DO know maintainers in the FFMpeg community and you do actually care about the progress of the whole project, then please, for the sake of avcodec, allow me to talk to them and ask for an explanation or at least to take it into consideration so that we can change/adjust the patch and provide some feedback to Nicolas, otherwise we're all losing time for nothing.
For us, DolbyE and DolbyED2 decoding is something very important which we do on a daily basis.
I know that it might not be important for some people, but for some other it's a vital thing to have and work properly.
I mean, you're the developer of LAV filters, after all, aren't you? (Which I use, by the way, so thanks for that too) So if avcodec becomes better it's also gonna be a good thing for LAV, right? :)

[birdie]

Not sure what "FFmpeg developers" you are talking to, but if they were of the active kind, they surely would have noticed this project on the mailing list.

The development tree is here:
https://github.com/ffvvc/FFmpeg

Its still quite under development and not finished yet, but should be somewhat usable.

There is also a GSoC 2023 project (https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2023#AssemblycodeforVVCdecoder) listed to enlist a student to help with writing Assembly for it, as well as a general task to get involved with work on it, if you need any more "evidence" that its a real thing endorsed by the FFmpeg project itself.

Woah, that looks amazing. A single person endeavour so far but it's quite active.

[FranceBB]

Woah, that looks amazing. A single person endeavour so far but it's quite active.

that was my same reaction.
I have no idea who nuomi2021 is, but looks like he's doing everything on his own with 130 commits O_O

[birdie]

BTW, I wasn't too wrong: development (of ffmpeg's own VVC decoder) started (https://github.com/ffvvc/FFmpeg/commit/58adf8866bc1f4e564dac39e64fd14b2ec937e3e) only on January 14th, 2023, i.e. just a month ago.

[nevcairiel]

Thats when the first version was published, you don't stamp that much out in a day. Some of the code has a 2021 copyright header. Not that people can't make mistakes in putting those in, and without the author telling us its impossible to know, but I would bet a good part of 2022 was this already being worked on.

[birdie]

Thats when the first version was published, you don't stamp that much out in a day. Some of the code has a 2021 copyright header. Not that people can't make mistakes in putting those in, and without the author telling us its impossible to know, but I would bet a good part of 2022 was this already being worked on.

Regardless it's great it's being worked on, albeit it seems like it's too late. The format was finalized over two years ago.

[benwaggoner]

Regardless it's great it's being worked on, albeit it seems like it's too late. The format was finalized over two years ago.
A couple-three of years from standardization to practical real-world use is pretty standard. Encoders need to be made and tuned, decoders need to be designed and shipped in products, etc.

HEVC was standardized in 2013 and didn't see much use until 2015. And since it was pretty much required to do practical 4K and HDR, there was a lot more appetite to use it an an early stage of development. Broad use of HEVC for 1080p SDR stuff was more around 2017.

VVC is a great codec, but there isn't some huge new market it enables like HDR, so implementers are more inclined to wait until it is end-to-end capable of handling current scenarios at much lower bitrates.

[rwill]

VVC is a great codec, but there isn't some huge new market it enables like HDR, so implementers are more inclined to wait until it is end-to-end capable of handling current scenarios at much lower bitrates.

From what I remember VVC was positioned as the codec to enable 8k. I guess there is just not that much demand for that amount of pixels currently, except for maybe 360° videos or similar.

Maybe 1080p HDR is enough for the viewing setup most people have anyway...

[FranceBB]

From what I remember VVC was positioned as the codec to enable 8k. I guess there is just not that much demand for that amount of pixels currently


Could be.
Japan also seems to be the only country currently broadcasting 8K contents (mostly documentaries or opera concerts), while other countries have only done sporadic tests on single events. They (the Japanese) even went to Milan to record at the "La Scala" theatre in Italy (its English meaning would be "The stair") and they didn't need any external help. They had their own cameras, lenses, video mixers, ingest, etc and I'm told they did everything on their own. Unfortunately I couldn't see any of that 'cause I wasn't invited... :(
Anyway, they're airing in H.265 mostly 'cause there aren't yet any widespread hardware encoder for H.266 VVC nor hardware decoders in commercial set-top-boxes or TVs. It would be interesting to know if they have any plan to switch to H.266 VVC once it becomes widely available, but unfortunately I don't know anybody at NHK to ask that... :(

On top of that, I also don't live anywhere near the footprint of BSAT 4A 110.0°E 11977 nor have an H.265 8K compatible receiver to get the NHK BS 8K feed either :(

https://sky-brokers.com/wp-content/uploads/2021/02/BSat-4a-Ku-band-coverage-500x333.png

[olduser217]

Could be.
Japan also seems to be the only country currently broadcasting 8K contents (mostly documentaries or opera concerts), while other countries have only done sporadic tests on single events. [/IMG]

China has an 8K channel since January 2022, using China AVS3 though.

https://zh.wikipedia.org/wiki/%E4%B8%AD%E5%A4%AE%E5%B9%BF%E6%92%AD%E7%94%B5%E8%A7%86%E6%80%BB%E5%8F%B08K%E8%B6%85%E9%AB%98%E6%B8%85%E9%A2%91%E9%81%93

[benwaggoner]

From what I remember VVC was positioned as the codec to enable 8k. I guess there is just not that much demand for that amount of pixels currently, except for maybe 360° videos or similar.
Yeah, 4K YUV pixels appears to be sufficient to saturate the human visual system at a viewing distance where the viewing angles to the sides of the screen are acceptable.

Maybe 1080p HDR is enough for the viewing setup most people have anyway...
For a lot of people it will be enough, and it's generally enough for SDR. HDR benefits more from higher resolutions as it can have way higher local contrast. I think 1440p would have hit perceptual saturation for SDR.

[Balling]

ticket there's only someone who uses the nickname Elon Musk (almost definitely not the *real* Elon Musk)

That is Paul B Mahol aka richardpl. almost is the keyword here, I am not sure it is even his real name.

[FranceBB]

By the way, thank you, Balling for letting me know that pinging the mailing list is normal. I tried again, let's see how it goes this time. I mean, in the whole ticket you seem to be the only one who replied and actually cared...
Hopefully the question and reply between me and you there will keep it up in the list until some of the maintainers will care...

[LigH]

New uploads: [Windows][GCC 12.2.0][64 bit]

VTM Encoder/Decoder Version 19.2 (https://www.mediafire.com/file/q8wdc6ov1lr0ozy/VTM_19.2_2a4ebfe9.7z/file) 2a4ebfe9

Fraunhofer VVC Encoder ver. 1.7.0 (https://www.mediafire.com/file/2ir8lq1ah0ji1la/vvenc_1.7.0-4d3db39.7z/file) 4d3db39

Fraunhofer VVC Decoder ver. 1.6.1 (https://www.mediafire.com/file/z1sg9wxfyt0nsp8/vvdec_1.6.1-36a6d13.7z/file) 36a6d13

[~ VEGETA ~]

is there any concise explanation of how VVC\H266 works? not too detailed and technical, similar to HEVC explanation in HEVC forums.

also, is it supported in mpv or so yet?

[FranceBB]

is there any concise explanation of how VVC\H266 works?

Well, for those who can read in Italian I explained it in one of my academic papers here: Link (https://view.publitas.com/p222-8308/francesco-bucciantini-utilizzo-delle-trasformate-nella-codifica-delle-immagini-fisse-in-movimento-ed-audio/page/150) (There are also pictures ehehehehe).

however since this is an English-speaking forum, I'll translate a few lines of what I wrote:


The new codec was developed starting from H.265 but introduced new encoding techniques and new optimizations; for instance prediction and motion-compensation were improved and concepts like Prediction Unit (PU) and Transform Unit (TU) have been removed. The main difference between H.265 and H.266 is that the first uses a Quad-Tree (QT) structure, while the second uses an MTT partition structure which includes the QT. In H.265 each frame is divided in several CTU (Coding Tree Unit). Each CTU has a block of luma and two blocks of chroma with corresponding sizes. The maximum size available for the luma block is 128x128 and the maximum for the chroma is 64x64. Besides, only the QT partition type is available for H.265, which limits the shape of the sub-CU to a square. In H.266 we have instead the MTT partition structure which includes 5 structures: BT_H (Horizontal Binary Tree Partition), BT_V (Vertical Binary Tree Partition), TT_H (Horizontal Ternary Tree Partition), TT_V (Vertical Ternary Tree Partition) and QT. Among them, the size ratio of the 3 parts in the partition structure is 1:2:1. The MTT partition structure allows the CU to be partitioned in an asymmetric way.


There are lots of other things to talk about like the transform used, plenty of new coding tools etc, but I can't translate my whole paper to English.

I'm pretty sure there are lots of very valid articles in English across the internet, but if you can't find any and you're curious, I think Google Translate *should* be able to translate my paper to English automatically for you. ;)


EDIT: Wait, perhaps you meant how the Fraunhofer's VVC Encoder works and not how the VVC/H.266 codec works? If that's the case, just take a look at our discussion from a while ago here: https://forum.doom9.org/showthread.php?t=174940&page=24

and you can start from a base cmd of:

ffmpeg.exe -i "AVS Script.avs" -strict -1 -an -f yuv4mpegpipe - | vvencapp.exe -i - --preset medium --format yuv420 --bitrate 25000 --profile auto --level 5.0 --passes 1 --output "VVC.h266"

pause

and then experiment



also, is it supported in mpv or so yet?


Yes... No... It's complicated.
Yes if you compile with a custom patch.
No if you use the standard binaries automatically compiled from the latest master.
Also, MPV leverages on FFMpeg and the best software decoder we have right now is VVDec but the patch to integrate it to master has been rejected by the FFMpeg devs 3 times. A friend of mine went to the last convention in person and said that it's coming so... if it wasn't "3rd time lucky" it will probably be "4th time lucky", but in the meantime one guy is also developing his own decoder within libav so that decoding won't depend on Fraunhofer (the author of VVDec) but rather be integrated within the other decoders, so now we don't know whether they're gonna wait for it and integrate it instead of VVDec or whether they're gonna integrate VVDec first and then replace it with the libav implementation or if they'll just keep both.

As I said, it's a mess.

[~ VEGETA ~]

thanks for your quick response.

I appreciate if you can write a new thread putting some very basic not-so-technical brief explanation. I know it is hard but it is not like writing technical papers, just specifying stuff so we can understand how the codec works and why it is hugely better than hevc despite using the same method of motion-estimation, referencing,etc..

I don't think any encoder\decoder is usable now, we need years.

[Dann0245]

thanks for your quick response.

I appreciate if you can write a new thread putting some very basic not-so-technical brief explanation. I know it is hard but it is not like writing technical papers, just specifying stuff so we can understand how the codec works and why it is hugely better than hevc despite using the same method of motion-estimation, referencing,etc..

I don't think any encoder\decoder is usable now, we need years.

There is a MPV mod which uses vvdec for decoding VVC. https://github.com/MartinEesmaa/VVCEasy/blob/master/MPV.md#download-mpv-windowsandroid-player-libvvdec--xhe-aac-plugin
VVdec performance is not good as (AV1) dav1d decoder, but that is the only VVC playable right now.

VVC samples:
https://drive.google.com/drive/folders/1JK1-k2_EfcgvQgQDzWRmBw7VgQLBaNI4
https://www.isize.co/portfolio/demo2/
https://www.dropbox.com/s/v5oforc2nqqul8v/MOS__VVC_HEVC_1.8m_3.0m_Oct16_2019.zip?dl=0

[LigH]

To be of practical use, ffmpeg and related projects would also need to detect a VVC stream inside containers like MP4; but nobody really takes my bug report serious, yet, although it should be a small task, compared to implementing a whole decoder.

[FranceBB]

nobody really takes my bug report serious, yet

if it can make you feel any better, they've been actively ignoring me as well...

[birdie]

The SpinDigital latest/last VVC patch series allows ffmpeg to encode and decode (read play in mpv) VVC/H.266 but it's not complete yet.

For instance I couldn't mux an elemental H.266 stream with AAC audio into mkv but it worked for mp4 (or was it vice versa - I don't remember now).

Also, VVC decoding [using vvdec] requires a lot of CPU resources - it's comparable to software decoded AV1.

vvdec really could use more optimizations.

If anyone's interested I can upload/share my ffmpeg/mpv builds for Fedora 37 x86_64. Don't ask for your own distro build as I'm on vacation now and my laptop is not suitable for firing up VMs with your favourite distro, let alone building software.

[FranceBB]

It's your lucky day, Artem, 'cause I'm on Fedora xD

[Jamaika]

For instance I couldn't mux an elemental H.266 stream with AAC audio into mkv but it worked for mp4 (or was it vice versa - I don't remember now).
Now I see. The funny thing now is that the unfinished decoder is on ffvvc. The MP4 decoder bass plugin for all VVC codecs was made by Martin. When it connects, muxer/demuxer should work thearetically. :D

[birdie]

It's your lucky day, Artem, 'cause I'm on Fedora xD

mpv / ffmpeg with VVC decoding support for Fedora 37 (https://mega.nz/file/rk0DkLqa#ZUcCmpIEB-3rDGI4ckk7gOeOGjgFQ9L-Ho4BStHCuQs).

The installation instructions are in the archive.

sha256sum ffmpeg+mpv-with-vvc-decoding-support-f37.tar.xz
c6fc12b058da084e2695a01e6ac595f5f57bb4c6bc2d3864c0e065531cd79dc0 ffmpeg+mpv-with-vvc-decoding-support-f37.tar.xz

[FranceBB]

Thank you! :D
Tested right up and it's actually working on my Fedora 37 ;)

[birdie]

Thank you! :D
Tested right up and it's actually working on my Fedora 37 ;)

Could you test 4K 60fps video playback? Specifically this (https://www.elecard.com/storage/video/NovosobornayaSquare_3840x2160.bin) one? Other (https://www.elecard.com/videos) clips.

Can your rig play it without dropping frames? ;-) Press Shift + I too see the statistics - most importantly "Dropped frames".

My Core i5 6200U can barely handle a 1080p clip. Near 100% CPU use and almost zero headroom.

[Jamaika]

Test ffmpeg + vvc
ffmpeg.exe -i "iphone6s_4k.mov" -c:v libuvg266 -vb 3000k -c:a ac3 -ac 2 -ab 128k -s 1920x1080 -frames 100 -pix_fmt yuv420p output_uvg266.mts --> OK
ffmpeg.exe -i "iphone6s_4k.mov" -c:v libuvg266 -vb 3000k -c:a ac3 -ac 2 -ab 128k -s 1920x1080 -frames 100 -pix_fmt yuv420p output_uvg266.mov --> decoder ffvvc + vvc_mp4toannexb_bsf.c MartinEesmaa Error {no header}
ffmpeg.exe -i "iphone6s_4k.mov" -c:v libuvg266 -vb 3000k -c:a ac3 -ac 2 -ab 128k -s 1920x1080 -frames 100 -pix_fmt yuv420p output_uvg266.mkv --> no file

ffmpeg.exe -i "iphone6s_4k.mov" -c:v libxeve -vb 3000k -c:a ac3 -ac 2 -ab 128k -s 1920x1080 -frames 100 -pix_fmt yuv420p output_xeve.mts --> no file
ffmpeg.exe -i "iphone6s_4k.mov" -c:v libxeve -vb 3000k -c:a ac3 -ac 2 -ab 128k -s 1920x1080 -frames 100 -pix_fmt yuv420p output_xeve.mov --> OK
ffmpeg.exe -i "iphone6s_4k.mov" -c:v libxeve -vb 3000k -c:a ac3 -ac 2 -ab 128k -s 1920x1080 -frames 100 -pix_fmt yuv420p output_xeve.mkv --> no file

ffmpeg.exe -f avs3 -i "SFTI_1920x1080.bin" -c:v libx264 -vb 3000k -an -s 1920x1080 -pix_fmt yuv420p output_x264.mov --> error {no frames}
ffmpeg.exe -f vvc -i "NovosobornayaSquare_1920x1080.bin" -c:v libx264 -vb 3000k -an -s 1920x1080 -pix_fmt yuv420p output_x264.mov --> error {no file}
[vvc @ 0000025b0ee2b5f0] No start code is found.
[vvc @ 0000025b0ee2b5f0] Error splitting the input into NAL units.

[benwaggoner]

Also, VVC decoding [using vvdec] requires a lot of CPU resources - it's comparable to software decoded AV1.

vvdec really could use more optimizations.
Honestly "comparable to SW AV1" is a pretty big accomplishment this early in VVC's life cycle, and speaks to a real good job of balancing decoder cost/complexity with compression efficiency gains.

AV1 is a bear to implement in hardware.

[hajj_3]

VeriSilicon delivered multi-format hardware video decoder Hantro VC9000D supporting 8K@120FPS VVC/H.266 to customers

source: https://www.verisilicon.com/en/PressRelease/HantroVC9000D

[FranceBB]

Could you test 4K 60fps video playback?

Dude, you wanna kill my CPU? XD

Jokes aside, I run Fedora on my personal computer at home, so it's not really powerful like the Intel Xeon workstations I have at work (20c/40th) or the servers I have there (56c/112th), it's just a puny little i7 6700HQ with 4c/8th at 2.60GHz and no AVX-512 just AVX2 (yes, it could go higher like 3.5GHz single core or 3.2GHz all cores, but it would start throttling like crazy, so...)
I use it mainly to read my email, browse the internet, post random stuff on Doom9, Facebook, Linkedin, occasionally watch YouTube (mainly Sky News or Linus Tech Tips) etc.
I mean, all very basic stuff.


Anyway, FULL HD H.266 VVC playback, no problem, but with UHD 60p it was begging me to pull the plug as it just wanted to die at 95°C, all cores 100%.


TL;DR no, I cannot play UHD 60p H.266 VVC without dropping frames on a 4 core laptop (nor I expected to).

Honestly "comparable to SW AV1" is a pretty big accomplishment this early in VVC's life cycle

It's not comparable, by the way.
In my test AV1 is lighter than H.266 VVC, probably because they had a lot of time to optimize software decoding.

[birdie]

Dude, you wanna kill my CPU? XD

Jokes aside, I run Fedora on my personal computer at home, so it's not really powerful like the Intel Xeon workstations I have at work (20c/40th) or the servers I have there (56c/112th), it's just a puny little i7 6700HQ with 4c/8th at 2.60GHz and no AVX-512 just AVX2 (yes, it could go higher like 3.5GHz single core or 3.2GHz all cores, but it would start throttling like crazy, so...)
I use it mainly to read my email, browse the internet, post random stuff on Doom9, Facebook, Linkedin, occasionally watch YouTube (mainly Sky News or Linus Tech Tips) etc.
I mean, all very basic stuff.


Anyway, FULL HD H.266 VVC playback, no problem, but with UHD 60p it was begging me to pull the plug as it just wanted to die at 95°C, all cores 100%.


TL;DR no, I cannot play UHD 60p H.266 VVC without dropping frames on a 4 core laptop (nor I expected to).



It's not comparable, by the way.
In my test AV1 is lighter than H.266 VVC, probably because they had a lot of time to optimize software decoding.

LOL. OK ;-) Thanks.

Yeah, sorry, I stand corrected, currently software VVC decoding using VVdeC is considerably more CPU intensive than AV1 decoding.

Sorry for misleading people earlier. My Ryzen 7 5800X chewed VVC 4K 60fps no problem and I didn't quite pay attention to power consumption or CPU usage. It must have been a lot higher than AV1.

[birdie]

From the lead Fraunhofer HHI VVC developer, Adam Wieckowski :

AV1 decoding is really much more optimized. The dav1d decoder has more lines of assembly code than Linux kernel. We don't have the knowledge or the resources to put in this kind of work.

To be fair, the best way to improve vvdec right now would be to rewrite it, because the performance is bound by the software structure that we inherited from VTM, even if heavily optimized. And we are not going to do this. We are still working on minor improvements, but don't expect really big leaps for vvdec anytime soon. ffvvc might someday be more efficient than vvdec, but by that time I expect HW support to be fairly broad.

The only bigger thing being worked on right now is the error resilience.

[FranceBB]

My Ryzen 7 5800X chewed VVC 4K 60fps no problem

ehehehe that's an 8c/16th 3.8GHz (max 4.7GHz) desktop CPU from 2020, no wonder it managed to decode it unlike my 4c/8th 2.6GHz laptop CPU from 2015 :P

Even benchmark values here get to the point of ridiculous in favor of your desktop CPU xD Intel i7 6700HQ vs AMD Ryzen 7 5800X (https://cpu.userbenchmark.com/Compare/Intel-Core-i7-6700HQ-vs-AMD-Ryzen-7-5800X/m34954vs4085)

[benwaggoner]

Sounds like we need the dav1d equivalent for VVC. Aomdec was similar to the Fraunhofer work here: optimizing the reference decoder, but not attempting to build a ground-up performance optimized decoder for real-world use.

[LigH]

From the lead Fraunhofer HHI VVC developer, Adam Wieckowski :

Does this quote have a shareable source?

[birdie]

Does this quote have a shareable source?

This (https://github.com/fraunhoferhhi/vvdec/issues/132#issuecomment-1479376672).

[DTL]

From the lead Fraunhofer HHI VVC developer, Adam Wieckowski :

Simple (and cheap to develop) C-reference implementation may be only for quality comparison. It will be truly free opensource working demo of a new codec. Github friendly. And to show the benefit from new version in compare with old products. For general industry it may be completely zero reason to invest into SIMD-optimized very hard to develop implementation for general purposes CPUs with SIMD co-processors just to make freeware version with no commertial benefit. For the quickly shrinking number of PC real users. The commertial developemnt is oriented into real market with real number of users to get money. May you can found ASIC for VVC decoding in some new smartphone in a few months later and it will outperform many massively-multicore expensive Xeons.

If codec will be accepted by industry it will be implemented in ASIC with all requirement performance for enduser setup (set-top-box or internal display decoder or a chip for handheld smartphone and so on).

[birdie]

VVenC 1.8 has been released (https://github.com/fraunhoferhhi/vvenc/releases/tag/v1.8.0).

Changes over v1.8.0-rc1

deprecated obsolete chroma QP control mechanism (to be removed in the next release)
removed deprecated parameters for partitioning control


Changes over v1.7.0

vvencFFapp removed from default installation
Speedups (~15% for faster/~5% for slower/~10% for other presets)
Improved error messages
Added temporal ALF APS prediction, closing the efficiency gap between single- and multi-threaded operation
Extended BIM by extrapolating parameters to non MCTF-filtered frames
Various fixes
Usability improvements
Various improvements

[MartinEesmaa]

I just want to let note, that I updated new FFmpeg master and MPV with VVCEasy new builds. I tried ffvvc in Windows, but it was error, so I switched from ffvvc to external VVC decoder of my own repository.

https://github.com/MartinEesmaa/VVCEasy/commit/39f09eda995163bfa3d47df0fbacc45942bb0420
https://github.com/MartinEesmaa/VVCEasy/commit/b60990621852cb62eb82142055eff0809530813e

- Martin Eesmaa

[Gravitator]

Всем привет!
Martin Eesmaa, help?
ffmpeg -i space_6s.mkv -f yuv4mpegpipe - | vvencapp --y4m -i - --fps 24000/1001 --preset fast -q 30 -o y4m.266
av_interleaved_write_frame(): Broken pipe
[out#0/yuv4mpegpipe @ 000001fdd23bac00] Error muxing a packet
[out#0/yuv4mpegpipe @ 000001fdd23bac00] Error writing trailer: Broken pipe

> sample (https://files.videohelp.com/u/227452/space_6s.mkv)

[MartinEesmaa]

Hi, Gravitator!

It seems vvencapp reported an error message of your sample file:
Parameter Check Error: Detected non-standard Frame Rate 13978/583 (23.98 Hz). Default TicksPerSecond (27000000) can not be used. possible TicksPerSecond: 8149174

You need to add --tickspersec -1 or possible number of console said example 8149174 on vvencapp console command to encode probably VVC video.

I encoded your sample file on my FFmpeg VVCEasy command, but three duplicated frames:
ffmpeg_vvceasy -i space_6s.mkv -c:v libvvenc -preset faster -b:v 0 -qp 30 y4m.266
frame= 149 fps= 16 q=0.0 Lsize= 902kB time=00:00:05.96 bitrate=1238.5kbits/s dup=3 drop=0 speed=0.631x
video:902kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000000%

- Martin Eesmaa

[Gravitator]

It doesn't help.

[MartinEesmaa]

Why it doesn't help?

I know why ticks per second could be quite moderate difficult, but I hope Multicoreware x266 encoder doesn't need ticks per second necessary, so we should wait a little bit to get x266 encoder in H2 2023.

Here is the transcoded from your matroska sample file to Y4M report:
YUV4MPEG2 W1920 H1080 F13978:583 Ip A1:1 C420mpeg2 XYSCSS=420MPEG2

Try change from F13978:583 to F24000:1001 without using tickspersecond command.

- Martin Eesmaa

[Gravitator]

The output of the parameter validation error continues.

[Gravitator]

This problem has a connection with the output of yuv4mpegpipe (rawvideo goes without an error).

[MartinEesmaa]

Oh ok, I see the rawvideo does not have problems, but Y4M does only some errors for some reasons of frame rate per second.
I looked issue for reference: https://github.com/fraunhoferhhi/vvenc/issues/252.
This could be bug for Fraunhofer HHI VVC encoder.

Maybe I encoded your sample file to libx264 with matroska container without duplicates frames, but encoding to raw bitstream reports duplicate frames. So I think VVC matroska is not finished yet.

I think Fraunhofer HHI VVC encoder is experimental I'd say, but I recommend we wait for Multicoreware x266 encoder or just make issue/discussion to vvenc github repository.

- Martin Eesmaa

[Gravitator]

They are already treating > https://github.com/fraunhoferhhi/vvenc/pull/255

[Gravitator]

Replace --tickspersecond -1 with --tickspersec -1 > It's going fine now :o

[MartinEesmaa]

Sorry, my bad. It's tickspersec, not tickspersecond. I hope the tickspersec -1 is gonna encode probably.

- Martin Eesmaa

[Yups]

chipsandcheese compared HEVC, AV1, VVC....interesting read.

Codecs for the 4K Era: HEVC, AV1, VVC and Beyond (https://chipsandcheese.com/2023/04/16/codecs-for-the-4k-era-hevc-av1-vvc-and-beyond/)

[birdie]

chipsandcheese compared HEVC, AV1, VVC....interesting read.

Codecs for the 4K Era: HEVC, AV1, VVC and Beyond (https://chipsandcheese.com/2023/04/16/codecs-for-the-4k-era-hevc-av1-vvc-and-beyond/)

From the research: "VVenC is still in heavy development and doesn’t currently support CRF. Therefore, we use the next best option – two-pass variable bitrate (VBR) – for VVC"

What? What version did they use? From 2 years ago?

From https://github.com/fraunhoferhhi/vvenc/wiki/Usage

--qp,-q 32 Quantization parameter (0..63)

which is basically CRF.

[nevcairiel]

QP and CRF is not the same. CRF will modify the QP to compensate for frame complexity, providing similar "perceived" quality for all frames, while keeping bitrate in check.
Constant QP is the simplest compression mode you can think of, really, as you don't do any rate-control at all.

[hajj_3]

What? What version did they use? From 2 years ago?



it says they used v1.7.0 which was released 5 months ago.

[birdie]

A native VVC decoder has been submitted to FFmpeg: https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/#147681

There's a number of objections, so it's not yet a done deal.

[Dann0245]

Is VVC film grain synthesis real?

https://github.com/fraunhoferhhi/vvenc/issues/278

[quietvoid]

Film grain synthesis in VVC would probably be based on the H.274 Film grain characteristics SEI.
Given HEVC supports it, I assume VVC will as well.

[benwaggoner]

Film grain synthesis in VVC would probably be based on the H.274 Film grain characteristics SEI.
Given HEVC supports it, I assume VVC will as well.
The AV1 FGS implementation seems richer (although still with its own issues). And it's entirely post processing. I've heard interest in letting VVC be able to access that mode as well via SEI.

[ShortKatz]

A native VVC decoder has been submitted to FFmpeg: https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/#147681

There's a number of objections, so it's not yet a done deal.

Seems some parts have been checked in to the main code now. But I have no idea which parts and which VVC functions FFmpeg now has.

[birdie]

Seems some parts have been checked in to the main code now. But I have no idea which parts and which VVC functions FFmpeg now has.

Native VVC support is a go! I guess we'll have preliminary support very soon, in less than a month.

[ShortKatz]

Native VVC support is a go! I guess we'll have preliminary support very soon, in less than a month.

That would be wonderful. At the moment the decoder/encoder is still missing. You can mux a VVC stream from e.g. a MP4 container into a MKV container. But converting the VVC stream into any other format fails. Same for converting any video stream into VVC.

[birdie]

That would be wonderful. At the moment the decoder/encoder is still missing. You can mux a VVC stream from e.g. a MP4 container into a MKV container. But converting the VVC stream into any other format fails. Same for converting any video stream into VVC.

Muxer/demuxer/bitstream parser are already in. Decoder is on its way.

It's quite possible FFmpeg 6.1 will support VVC decoding. 6.2 surely will.

Sadly we have next to zero consumer devices supporting HW VVC decoding aside from two TV set models, that's it. Software VVC decoding is quite taxing though vvdec is not yet fully optimized, hopefully FFMpeg will be.

[FranceBB]

Muxer/demuxer/bitstream parser are already in. Decoder is on its way.

It's quite possible FFmpeg 6.1 will support VVC decoding. 6.2 surely will.

Nice. :D
Hopefully by the end of the years the x266 guys will be ready too with a public release and everything will come together.

So... if everything goes well, in 2024 we might finally begin to see the adoption of H.266, which is a good thing 'cause as soon as people are gonna start putting contents out there, manufacturers will jump in, I'm sure. :)

[birdie]

Oh, I've just found a huge number of VVC test/sample files (https://www.itu.int/wftp3/av-arch/jvet-site/bitstream_exchange/) in case someone is interested.

[ShortKatz]

Muxer/demuxer/bitstream parser are already in. Decoder is on its way.

It's quite possible FFmpeg 6.1 will support VVC decoding. 6.2 surely will.

This would be nice. If decoding works, then apps that are based on FFmpeg, like HandBrake, will support opening VVC files.




Sadly we have next to zero consumer devices supporting HW VVC decoding aside from two TV set models, that's it. Software VVC decoding is quite taxing though vvdec is not yet fully optimized, hopefully FFMpeg will be.

I'm pretty sure, if we have VVC software support, hardware support will follow. There is already the MediaTek Pentonic series and the Realtek RTD1319D that supports VVC.

[benwaggoner]

This would be nice. If decoding works, then apps that are based on FFmpeg, like HandBrake, will support opening VVC files.
And getting decoding working is the easiest and most essential aspect of getting the whole ecosystem working. If you can't play back, you can't troubleshoot!


I'm pretty sure, if we have VVC software support, hardware support will follow. There is already the MediaTek Pentonic series and the Realtek RTD1319D that supports VVC.
Hardware is coming regardless, but software decoders are very valuable to an ecosystem as well. I've heard from multiple sources that VVC decoders are simpler and require less compute than AV1 decoders, and thus will be faster to get well optimized. That said, getting a good AV1 SW decoder made was a high priority for AOM, and I don't know that anyone is putting equivalent engineering effort into SW VVC decoders at this point.

[FranceBB]

This would be nice. If decoding works, then apps that are based on FFmpeg, like HandBrake, will support opening VVC files.

Yep, once FFMpeg is a done deal with libav, we'll have indexers in Avisynth and VapourSynth, decoders in MPV, VLC and plenty of other players, support in programs like VirtualDub, Avidemux, Xmedia Recode etc etc etc.

I mean, nowadays pretty much everything relies on it (not necessarily on FFMpeg itself, but rather on libavcodec), so if it truly is an internal decoder and not an external one (like VVDec), then I would expect it to be in libav and therefore everything using libav will "automagically" gain support. :)


If you can't play back, you can't troubleshoot!

pretty much xD

[vahid]

Hi. I don't know I should ask my question here or not. However, How do I go about extracting motion vectors from vtm software for VVC and have the value of each motion vector?
For example for GOP: I P P P ... or I P B B B P

[Jamaika]

Hi. In libbpg for jvetvvc 19.2 GOP : I P P P ... use:

if (s->params.intra_only) {
add_opt(&argc, argv, "--BitstreamFile=image.vvc");
add_opt(&argc, argv, "--GOPSize=1");
add_opt(&argc, argv, "--DecodingRefreshType=1");
add_opt(&argc, argv, "--IntraPeriod=1");
add_opt(&argc, argv, "--OnePictureOnlyConstraintFlag=1");
add_opt(&argc, argv, "--GciPresentFlag=1");
add_opt(&argc, argv, "--Level=15.5");
add_opt(&argc, argv, "--Tier=high");

add_opt(&argc, argv, "--SearchRange=64");
add_opt(&argc, argv, "--CIIP=0");
add_opt(&argc, argv, "--AffineAmvr=0");
add_opt(&argc, argv, "--LMCSUpdateCtrl=1");
add_opt(&argc, argv, "--LMCSOffset=0");

add_opt(&argc, argv, "--ISPFast=1");
add_opt(&argc, argv, "--FastMIP=1");
add_opt(&argc, argv, "--FastLFNST=1");
add_opt(&argc, argv, "--FastLocalDualTreeMode=0");

add_opt(&argc, argv, "--AffineAmvrEncOpt=0");
add_opt(&argc, argv, "--MmvdDisNum=8");

add_opt(&argc, argv, "--TemporalSubsampleRatio=8");
} else {
add_opt(&argc, argv, "--BitstreamFile=animation.vvc");
add_opt(&argc, argv, "--GOPSize=1");
add_opt(&argc, argv, "--DecodingRefreshType=2");
add_opt(&argc, argv, "--IntraPeriod=-1");
add_opt(&argc, argv, "--FastSearch=1");
add_opt(&argc, argv, "--SearchRange=96");
add_opt(&argc, argv, "--BipredSearchRange=4");

add_opt(&argc, argv, "--IntraQPOffset=-1");
add_opt(&argc, argv, "--LambdaFromQpEnable=1");

add_opt(&argc, argv, "--CIIP=1");
add_opt(&argc, argv, "--AffineAmvr=0");
add_opt(&argc, argv, "--LMCSUpdateCtrl=2");
add_opt(&argc, argv, "--LMCSOffset=1");
add_opt(&argc, argv, "--AllowDisFracMMVD=1");
add_opt(&argc, argv, "--ISPFast=0");
add_opt(&argc, argv, "--FastMIP=0");
add_opt(&argc, argv, "--FastLocalDualTreeMode=2");
add_opt(&argc, argv, "--MaxMergeRdCandNumTotal=5");
add_opt(&argc, argv, "--AffineAmvrEncOpt=0");
add_opt(&argc, argv, "--MmvdDisNum=6");
add_opt(&argc, argv, "--ALFAllowPredefinedFilters=1");
add_opt(&argc, argv, "--ALFStrengthTargetLuma=1.0");
add_opt(&argc, argv, "--ALFStrengthTargetChroma=1.0");
add_opt(&argc, argv, "--CCALFStrengthTarget=1.0");
add_opt(&argc, argv, "--EncDbOpt=1");

for(i = 0; i < s->frame_count - 1; i++) {
snprintf(buf, sizeof(buf), "--Frame%d=P 1 4 -6.5 0.2590 0 0 1.0 0 0 0 0 0 0 0 1 1 1 0 0 0 0 0", i + 1);
add_opt(&argc, argv, buf);
}

add_opt(&argc, argv, "--DeblockingFilterOffsetInPPS");
add_opt(&argc, argv, "--DeblockingFilterOffsetInPPS=1");
add_opt(&argc, argv, "--DeblockingFilterDisable=0");
add_opt(&argc, argv, "--DeblockingFilterBetaOffset_div2=-2");
add_opt(&argc, argv, "--DeblockingFilterTcOffset_div2=0");
add_opt(&argc, argv, "--DeblockingFilterCbBetaOffset_div2=-2");
add_opt(&argc, argv, "--DeblockingFilterCbTcOffset_div2=0");
add_opt(&argc, argv, "--DeblockingFilterCrBetaOffset_div2=-2");
add_opt(&argc, argv, "--DeblockingFilterCrTcOffset_div2=0");

add_opt(&argc, argv, "--TemporalFilter=0");

add_opt(&argc, argv, "--RateControl=0");
add_opt(&argc, argv, "--TargetBitrate=1000000");
add_opt(&argc, argv, "--KeepHierarchicalBit=2");
add_opt(&argc, argv, "--LCULevelRateControl=1");
add_opt(&argc, argv, "--RCLCUSeparateModel=1");
add_opt(&argc, argv, "--InitialQP=0");
add_opt(&argc, argv, "--RCForceIntraQP=0");
}

[vahid]

:thanks:thanksHi. In libbpg for jvetvvc 19.2 GOP : I P P P ... use:

add_opt(&argc, argv, "--CabacZeroWordPaddingEnabled=0");
add_opt(&argc, argv, "--VideoSignalTypePresent=0");
//add_opt(&argc, argv, "--MaxBytesPerPicDenom=0");
add_opt(&argc, argv, "--SEIToneMapExposureCompensationValueDenomIdc=0");
add_opt(&argc, argv, "--SEIChromaResamplingHorizontalFilterType=0");
add_opt(&argc, argv, "--SEIChromaResamplingVerticalFilterType=0");
add_opt(&argc, argv, "--SEIKneeFunctionNumKneePointsMinus1=0");
add_opt(&argc, argv, "--ChromaLocInfoPresent=0");
add_opt(&argc, argv, "--ConstrainedIntraPred=1");
add_opt(&argc, argv, "--Profile=main_444_16");
add_opt(&argc, argv, "--IntraPeriod=250");
add_opt(&argc, argv, "--DecodingRefreshType=1");
add_opt(&argc, argv, "--ReWriteParamSetsFlag=1");
int gop_size = 1;
snprintf(buf, sizeof(buf), "--GOPSize=%d", gop_size);
add_opt(&argc, argv, buf);

for(i = 0; i < gop_size; i++) {
snprintf(buf, sizeof(buf), "--Frame%d=P 1 3 0 0.4624 0 0 1.0 0 0 0 1 1 -1 0 0 0 0", i + 1);
add_opt(&argc, argv, buf);
}

[CodecWar]

Introduction:
In the realm of video coding, two prominent contenders, VVC (Versatile Video Coding) and AV1 (AOMedia Video 1), have been vying for the throne of next-generation video compression. A recent comparative study sheds light on the performance disparities between these codecs, providing valuable insights into their strengths and weaknesses. In this article, we delve into the study's findings, methodology, and implications for video enthusiasts and industry professionals.

Source : https://codecwar.com

Study Highlights:
The study examined 62 diverse video streams and drew several significant conclusions:

VVC Takes the Lead:
On average, the VVC reference codec outperformed AV1, delivering superior video quality. The study indicated that AV1 trailed behind VVC by approximately 7.12% across all analyzed video streams.

Codec Specifications:
The study employed VTM (Versatile Video Coding Test Model) implementation, revision 17.0, with the RA (Random Access) configuration, as the reference VVC codec. Meanwhile, AV1 was evaluated using the libAOM (AOMedia codec library) implementation, revision av1-normative, with the RA configuration.

Methodology:
To facilitate a fair and objective comparison, the study employed a BD-Rate (Bjontegaard Delta Rate) analysis with AOM PCHIP (Piecewise Cubic Hermite Interpolating Polynomial) interpolation. This method allowed for precise measurement and comparison of the PSNR (Peak Signal-to-Noise Ratio): Y metric, widely utilized to gauge video quality.

Implications and Future Prospects:
The findings of this comparative study have several implications for the video coding landscape. While VVC emerged as the stronger performer in the analyzed scenarios, AV1 should not be dismissed outright. The open-source nature of AV1, coupled with ongoing development and refinement efforts, presents the possibility of future improvements, narrowing the performance gap between the two codecs.

Additionally, industry professionals should consider the specific requirements of their use cases. Factors such as available bandwidth, hardware support, and compatibility across devices and platforms must be weighed when selecting a video codec. Both VVC and AV1 have unique features and advantages that make them suitable for different applications.

Conclusion:
The comparative study between VVC and AV1 has shed light on the performance disparities between these codecs. While VVC demonstrated superior video quality in this particular study, the dynamic nature of video coding warrants continuous evaluation and exploration. As technology advances and requirements evolve, the choice of a video codec should be carefully considered based on the specific needs of each scenario.

Research visualization:

http://forum.doom9.org/attachment.php?attachmentid=18436&stc=1&d=1689581413

http://forum.doom9.org/attachment.php?attachmentid=18437&stc=1&d=1689581432

http://forum.doom9.org/attachment.php?attachmentid=18438&stc=1&d=1689581459

http://forum.doom9.org/attachment.php?attachmentid=18439&stc=1&d=1689581475


FULL REPORT with all the charts (avaliable after registration) :
https://codecwar.com/compare/vvc-vs-av1

[Jamaika]

I answer. How can you compile with frames IPPPP in jvetvvc?
It's complicated because jvetvvc has lot of features. Each new version of the codec may have changed functions.
JVETVVC has P/B frame limiter to 64. This can be increased by changing the MAX_GOP value.
How to decode such movie? Using jvetvvc decoder in this case only version 21.0.
Does ffvvc decode 444/420/rgb videos? Currently not decoding.

Example below:
del *.png
del *.jpg
ffmpeg_rsvg.exe -y -i "video.mp4" -s 360x180 -frames:v 33 image%%d.png
bpgenc_jvetvvc.exe -v -a -q 0 -b 8 -f 444 -c ycbcr_bt709 -m 9 image%%d.png -o output3.bpg
DecoderApp.exe -b animation.vvc -d 8 --SEIDecodedPictureHash=0 -o animation.yuv
ffplay_vvc.exe animation.vvc

[birdie]

I answer. How cam you compile an IPPPP movie in jvetvvc?
It's complicated because jvetvvc has lot of features and is test codec.
JVETVVC has P/B frame limiter of 64. This can be increased by changing the MAX_GOP value.
How to decode such a movie? Using jvetvvc decoder version 21.0.
The above functions are obsolete because they were for version 14.0
Does ffvvc decode 444/420/rgb videos? Currently not decoding.

Example below:
del *.png
del *.jpg
ffmpeg_rsvg.exe -y -i "video.mp4" -s 360x180 -frames:v 33 image%%d.png
bpgenc_jvetvvc.exe -v -a -q 0 -b 8 -f 444 -c ycbcr_bt709 -m 9 image%%d.png -o output3.bpg
ffplay_vvc.exe animation.vvc


Could you run whatever you had in mind through Deepl or Google Translate? It's really hard to understand what you meant.

[LigH]

New uploads: [Windows][GCC 13.1.0][64 bit]

VTM Encoder/Decoder Version 21.0 (https://www.mediafire.com/file/6yc9vdich3onw4j/VTM_21.0_d4aa80320.7z/file) d4aa80320

Fraunhofer VVC Encoder ver. 1.9.0-rc2 (https://www.mediafire.com/file/2ggyubnpsxarp13/vvenc_1.9.0-rc2-3fcfd93.7z/file) 3fcfd93

Fraunhofer VVC Decoder ver. 2.1.0 (https://www.mediafire.com/file/3p9gpvhehlhkml3/vvdec_2.1.0-5b31cd4.7z/file) 5b31cd4

[Jamaika]

Could you run whatever you had in mind through Deepl or Google Translate? It's really hard to understand what you meant.

There is nothing to understand. Example below with P frame limiter to 1024. I don't have time for that because there are still bugs in libbpg/jvet. This is the general scheme.
Why is it presented so intricately?
Manually typing functions in EncoderApp.exe --FrameX from 1 to 10000 is a bit of a hassle.
There is no way to add only P-frames in vvenc.

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

[benwaggoner]

There is nothing to understand. Example below with P frame limiter to 1024. I don't have time for that because there are still bugs in libbpg/jvet. This is the general scheme.
Why is it presented so intricately?
Manually typing functions in EncoderApp.exe --FrameX from 1 to 10000 is a bit of a hassle.
W vvenc nie ma możliwości dodawania tylko samych klatek P.
There is no way to add only P-frames in vvenc.
Is the goal to have 0 b-frames here? Can't that be set directly?

[Jamaika]

That's how I understood user vahid. For libbpg these frames-P called it as animated video in jvet(HM) HEVC .
I don't know what libheif came up with because he was supposed to add the vvc codec.

[vahid]

Ok. Thanks. I have two issues with VTM. 1) Can I have every desired GOP? even if it includes multiple P frames, such as I P P P P P? If it is so complicated, a simpler GOP structure like I P B B B P or I P B B .... is appropriate.
2) The main goal is to have the value of motion vectors that encoder send to channel. I want to extract only these values. However, it is important to have the motion vectors for each frame separately, as well as the values of each individual motion vector. Thus if I have motion vectors for a GOP structure such as I P B B B P, it would be very helpful.

[Jamaika]

Originally GOP Size must be between 1 and 64. For IPPP... GOP is always 1.
Motion vectors details are set in CTUsize. For jvetvvc this will be a problem. In the given example ctusize is added 32 when standard is 128. Unfortunately codec doesn't have thread support so you wait 20 minutes for FullHD screenshot.
https://www.mainconcept.com/mainconcept-and-fraunhofer-iis-to-showcase-the-future-of-video-and-audio-with-vvc-and-mpeg-h-audio
https://www.youtube.com/watch?v=mtaC_lQO2-4
I think that in a year MainConcept VCC codecs will be in all paid editors and it will be the easiest way for you to test the movie.

[vahid]

Thanks a lot. Howeverو I only want to have value of motion vectors separately for usual GOP. Is it so complicated or is it impossible now?

[birdie]

GStreamer is working on a VVC demuxer/parser/decoder (using vvdec): https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2842

And a free MacOS video player with full VVC decoding support has been released: https://www.elmedia-video-player.com/

Things are moving.

[birdie]

And here's a 2023 codec adoption roadmap from Rethink Technology Research:

[vahid]

How about PUs of I frames? extract the 4x4's PUs of each I frame separately in VVCSoftware_VTM?

[Jamaika]

I don't think this is question for this forum. You have to be codec developer.
https://stackoverflow.com/questions/28014901/why-does-hm-subdivide-a-cu-into-pus-with-identical-mvs
These are the functions for JCTVC HEVC
ctu->getTotalNumPart() == 256
ctu->getDepth(48) == 3
ctu->getPredictionMode(48) == INTER_MODE
ctu->getPartitionSize(48) == Nx2N
https://cdnintech.com/media/chapter/52002/1512345123/media/fig1.png
https://www.intechopen.com/chapters/52002
extract the 4x4's PUs of each I frame separately in VVCSoftware_VTM?
ptu->getTotalNumPart() == 256
ptu->getDepth(48) == 5
ptu->getPredictionMode(48) == INTRA_MODE
ptu->getPartitionSize(48) == NxN
Your case is definitely Intra mode and depth 5. For VVC max CU is 128x128. I just don't know what the function equivalents are in JVETVVC. Officially JVETVVC isn't PTU function
partitioner.currPartIdx() == 256
partitioner.currDepth == 5

[vahid]

:thanks:I don't think this is question for this forum. You have to be codec developer.
https://stackoverflow.com/questions/28014901/why-does-hm-subdivide-a-cu-into-pus-with-identical-mvs
These are the functions for JCTVC HEVC
ctu->getTotalNumPart() == 256
ctu->getDepth(48) == 3
ctu->getPredictionMode(48) == INTER_MODE
ctu->getPartitionSize(48) == Nx2N
https://cdnintech.com/media/chapter/52002/1512345123/media/fig1.png
https://www.intechopen.com/chapters/52002
extract the 4x4's PUs of each I frame separately in VVCSoftware_VTM?
ptu->getTotalNumPart() == 256
ptu->getDepth(48) == 5
ptu->getPredictionMode(48) == INTRA_MODE
ptu->getPartitionSize(48) == NxN
Your case is definitely Intra mode and depth 5. For VVC max CU is 128x128. I just don't know what the function equivalents are in JVETVVC. Officially JVETVVC isn't PTU function
partitioner.currPartIdx() == 256
partitioner.currDepth == 5

[birdie]

MSU has released "MSU Video Codecs Comparison 2022 (https://www.compression.ru/video/codec_comparison/2022/main_report.html)".

Tencent-TVC and Tencent266 codecs have beaten everything under the sun but you cannot download or use either.

And here's a August 2023 VVC adoption report (https://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=159880) from Streaming Media.

Meanwhile there's been no news in regard to x266 but H2 is not over yet.

[Atak_Snajpera]

MSU has released "MSU Video Codecs Comparison 2022 (https://www.compression.ru/video/codec_comparison/2022/main_report.html)".

Tencent-TVC and Tencent266 codecs have beaten everything under the sun but you cannot download or use either.

And here's a August 2023 VVC adoption report (https://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=159880) from Streaming Media.

Meanwhile there's been no news in regard to x266 but H2 is not over yet.
Chinese BS...

[birdie]

Out of tree native VVC decoder for FFMpeg is now complete (https://github.com/ffvvc/FFmpeg/commit/a8d6e82539a19187129ae2f8510aa54791fc9131).

Now idea when it's gonna get merged.

[Jamaika]

Out of tree native VVC decoder for FFMpeg is now complete (https://github.com/ffvvc/FFmpeg/commit/a8d6e82539a19187129ae2f8510aa54791fc9131).

Now idea when it's gonna get merged.
Decoder is currently only 10bit 420/422 and doesn't support Intra Block Copy and Palette.
https://i.ibb.co/H7rPrVt/uiecfbv.png

[PatchWorKs]

On the other hand, it's the first time I hear about xin26x which could develop into a good encoder suite if the developers ever get to a stage where some effort is spent on subjective tuning.
Well, just discovered it on GH:

Xin26x is an univeral video encoder framework, which can accommodate all video coding standard on this planet so far.
It is optimized for real time video communication, live streaming application and offline video encoding.
It currently supports HEVC, AV1(I frame), VVC video coding standards.
It is a very high performance encoder.
It is well-structured for understandability, maintainability and scalability.
It is written from scratch and has a plain C API to enable a simple integration into other software.
It is very small footprint encoder, it takes very small memory requirement under restricted mode.


According to the Git (https://github.com/pigpeppa/xin26x), it's buildable and working (even if not complete -> check Todos (https://github.com/pigpeppa/xin26x#todo-lists))

Does anyone tested it ?

[ShortKatz]

Out of tree native VVC decoder for FFMpeg is now complete (https://github.com/ffvvc/FFmpeg/commit/a8d6e82539a19187129ae2f8510aa54791fc9131).

Now idea when it's gonna get merged.

Hope this gets merged soon into FFmpeg master. But the thread executor is also still missing.
http://ffmpeg.org/pipermail/ffmpeg-devel/2023-August/313669.html
Edit: Now it is not missing anymore.

[birdie]

Probably the first Android ROM with built in VVC support (it's not specified whether it's for encoding or decoding, I guess it's decoding only):

https://forum.xda-developers.com/t/rom-11-0_r71-jaguar-oneplus-9-pro-official-v36-updated-september-8-2023.4394057/post-88979437

For OnePlus 9.

[benwaggoner]

Probably the first Android ROM with built in VVC support (it's not specified whether it's for encoding or decoding, I guess it's decoding only):

https://forum.xda-developers.com/t/rom-11-0_r71-jaguar-oneplus-9-pro-official-v36-updated-september-8-2023.4394057/post-88979437

For OnePlus 9.
Software decoder or actual hardware one?

[birdie]

Software decoder or actual hardware one?

You can bet 100% it's a software decoder. There's been no SoCs for mobile phones with HW VVC decoding support yet.

I have a sneaking suspicion Qualcomm Snapdragon 3 will be the first to support HW VVC decoding. We'll learn about that in just a few months.

[birdie]

More patent pools:

https://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=161147

[benwaggoner]

You can bet 100% it's a software decoder. There's been no SoCs for mobile phones with HW VVC decoding support yet.

I have a sneaking suspicion Qualcomm Snapdragon 3 will be the first to support HW VVC decoding. We'll learn about that in just a few months.
Qualcomm wouldn't be surprising. And given the costs and variability of mobile bandwidth, it's the market where new codecs can have the quickest immediate customer benefit.

[hajj_3]

}I have a sneaking suspicion Qualcomm Snapdragon 3 will be the first to support HW VVC decoding. We'll learn about that in just a few months.

no vvc in that soc: https://www.qualcomm.com/products/mobile/snapdragon/smartphones/snapdragon-8-series-mobile-platforms/snapdragon-8-gen-3-mobile-platform

[birdie]

no vvc in that soc: https://www.qualcomm.com/products/mobile/snapdragon/smartphones/snapdragon-8-series-mobile-platforms/snapdragon-8-gen-3-mobile-platform

Right (https://docs.qualcomm.com/bundle/publicresource/87-71408-1_REV_B_Snapdragon_8_gen_3_Mobile_Platform_Product_Brief.pdf), that's a huge bummer (in VVC adoption) :-(

"Hardware-accelerated H.265, VP9, AV1 decoder".

Even SnapDragon 8 Gen 2 can decode 4K@30fps in software mode but battery life will be decimated.

[benwaggoner]

no vvc in that soc: https://www.qualcomm.com/products/mobile/snapdragon/smartphones/snapdragon-8-series-mobile-platforms/snapdragon-8-gen-3-mobile-platform
That is somewhat surprising, and disappointing.

[Emulgator]

Well, I wouldn't have expected VVCDec cast into mobile silicon this year.
Not from a chip manufacturer's view: energywise, bugfixwise, IP/patentwise I would have considered it too early days.
The few in business (only 2 or 3 fabs can do that, IIRC) got to deliver perfectly working batches in expensive 4nm for a few hard-earned dollars.
The slightest fault or unkept promise and the market will kill their margin.
Maybe the market will be ready to pay up again for the next feature set, on display end 2024, on the shelves 2025.
VVCDecoding effort will call for 3nm. Encoding ? way out.
Mobile devices can have 1TB on board today, mine from 2021 has 512GB, and I opted for AVC encoding, not HEVC.
No need for compressing the hell out of the private video, battery life will drop as we speak, and that counts as sale argument.

[kurkosdr]

That is somewhat surprising, and disappointing.
Nothing surprising here, very few people outside Doom9 have even heard of VVC, except perhaps 8K enthusiasts (all 3 of them) who may have heard it's the format intended for 8K broadcasts over sat or terrestrial (in the oft-chance such broadcasts ever happen). Hardware support for VVC is pretty slim (I am not gonna pretend 8K "Ultra-Ultra-HD" TVs are anything other than a niche, since they are basically an uncut motherglass of four UHD TVs posing as "innovation" that nobody cares about) and so is available VVC content. Everyone out there checks for HEVC and AV1 hardware support for 4K UHD resolutions, so that's what the industry is providing (for now, at least).

[benwaggoner]

Nothing surprising here, very few people outside Doom9 have even heard of VVC, except perhaps 8K enthusiasts (all 3 of them) who may have heard it's the format intended for 8K broadcasts over sat or terrestrial (in the oft-chance such broadcasts ever happen). Hardware support for VVC is pretty slim (I am not gonna pretend 8K "Ultra-Ultra-HD" TVs are anything other than a niche, since they are basically an uncut motherglass of four UHD TVs posing as "innovation" that nobody cares about) and so is available VVC content. Everyone out there checks for HEVC and AV1 hardware support for 4K UHD resolutions, so that's what the industry is providing (for now, at least).
VVC is getting momentum in living room devices already, and it is a big improvement over HEVC and AV1.

It doesn't enable any big high value content enabling features like HEVC did with HDR and 4K. HEVC was a particularly quickly adopted codec for those reasons.

[kurkosdr]

VVC is getting momentum in living room devices already, and it is a big improvement over HEVC and AV1.

It doesn't enable any big high value content enabling features like HEVC did with HDR and 4K. HEVC was a particularly quickly adopted codec for those reasons.
Out of curiosity, do you have an example of those living room devices? The only devices I've seen it in are 8K "Ultra-Ultra-HD" TVs (which is a gimmick less well-received by the public than stereoscopic 3D with none of the cool factor).

I want to see VVC becoming a thing in the broadcast world (terrestrial and satellite) where content fees/royalties don't matter and the 16Mbps minimum that HEVC requires for a UHD stream is just too much considering how crowded most multiplexes are. For example, the few countries here in Europe that have terrestrial UHD broadcasts (France and Spain) have 2 UHD channels max.

But again, I don't see VVC going anywhere because it seems broadcasters have settled on HEVC for UHD.

[hajj_3]

But again, I don't see VVC going anywhere because it seems broadcasters have settled on HEVC for UHD.

broadcasters are using hevc because there aren't many/any vvc set-top boxes available. Once companies can buy set-top boxes at a low cost with vvc then countries upgrading from older codecs will choose vvc.

[benwaggoner]

broadcasters are using hevc because there aren't many/any vvc set-top boxes available. Once companies can buy set-top boxes at a low cost with vvc then countries upgrading from older codecs will choose vvc.
Brazil used VVC + LC-EVC for the 2022 World Cup, using a very fashion-forward STB.

Adding a VVC decoder isn't going to impact the cost of a STB by more than a couple of dollars.

[hajj_3]

Brazil used VVC + LC-EVC for the 2022 World Cup, using a very fashion-forward STB.

Adding a VVC decoder isn't going to impact the cost of a STB by more than a couple of dollars.

few chipsets have vvc. You can't buy a cheap hisilicon or mediatek soc with vvc for example.

[kurkosdr]

Brazil used VVC + LC-EVC for the 2022 World Cup, using a very fashion-forward STB.
VVC + LC-EVC? Do we happen to know resolution, bit-depth, fps, and the bitrate used for those?

Adding a VVC decoder isn't going to impact the cost of a STB by more than a couple of dollars.
Amen. There is no reason UHD TVs that cost at least several hundred dollars shouldn't have an SoC capable of decoding VVC. it's the same short-sighted thinking that has kept terrestrial broadcasts in countries like the UK and Australia largely on MPEG2 SD: Too many TVs were sold without MPEG4 HD decoding support even after MPEG4 HD decoding became viable with an SoC, and now there is political resistance to discontinuing those MPEG2 SD services. Something similar is playing out today, with non-8K UHD TVs supporting only HEVC (which as said previously above cannot fit that many UHD channels in a mux). Imagine if HD had settled on MPEG2 or MPEG4 ASP, how few HD services we'd have. That's what's happening at the moment with UHD and HEVC.

[birdie]

SoCs supporting VVC decoding have existed for quite some time now (for more than a year):

https://en.wikipedia.org/wiki/Versatile_Video_Coding#Hardware

[hajj_3]

SoCs supporting VVC decoding have existed for quite some time now (for more than a year):

https://en.wikipedia.org/wiki/Versatile_Video_Coding#Hardware

the allegro and verisilicon are only ip blocks not chips. The mediatek chips are tv chips not set-top box chips. Only the realtek is a set top box soc. realtek charges much more than the competition for their socs which is why few devices use them.

[ksec]

That is somewhat surprising, and disappointing.

Especially Qualcomm has already show case VVC Hardware decoding in their Smartphone prototype this year. So I was expecting that to be announced with Snapdragon Gen 3.

There is a possibility that VVC decoding is there but disabled for various sort of reason.

Ateme has just announced their H.266 encoder.

[benwaggoner]

VVC + LC-EVC? Do we happen to know resolution, bit-depth, fps, and the bitrate used for those?
It was covered in a session at the SMPTE Media Technology Summit last month. I can't find a downloadable link to it somehow. Maybe it wasn't posted?

This is a pretty detailed link about it: https://www.frontiersin.org/articles/10.3389/frsip.2022.884254/full

[Jamaika]

LCEVC Decoder SDK
https://github.com/v-novaltd/LCEVCdec

[hajj_3]

https://accessadvance.com/wp-content/uploads/2023/11/2023Q4-VVC-Patent-Diagram-11-01-23-1536x1152.jpg

[Yups]

Intels next gen low power mobile chip Lunar Lake supports HW VVC decoding.

https://abload.de/img/3wmibf.png
https://forums.anandtech.com/threads/intel-meteor-arrow-lunar-panther-lakes-discussion-threads.2606448/page-142#post-41110064

[birdie]

That's really great, hopefully AMD will follow with either RDNA 3.5 (thought I don't have any hope for it, it sounds like a minor upgrade) or RDNA 4.0.

And it now sounds unlikely that NVIDIA will add a decoder in Blackwell, aka the GeForce 50 series but I won't be surprised if they do.

What I find befuddling is that there's been no news about x266 which was promised to be released in H2 2023. We are less than six weeks before the year end.

[kurkosdr]

What I find befuddling is that there's been no news about x266 which was promised to be released in H2 2023. We are less than six weeks before the year end.

They can always pull a Morotola and release right before H2 2023 expires.

For those not in the know, Motorola promised a "summer launch of Android 2.2 for Droid X" and they kept to the letter of their word by releasing Android 2.2 for the Droid X literally on the last day of summer:
https://finance.yahoo.com/news/2010-09-21-motorola-droid-x-getting-android-2-2-update-starting-tomorrow.html

Just don't ask how many unresolved issues were swept under the rug to achieve that.

[Emulgator]

Intels next gen low power mobile chip Lunar Lake supports HW VVC decoding.

Unfanned 8W power consumption, fanned 17-30W, thanks TSMC.
This is a big power saving achievement for any desktop and notebook segment.

So one may call that mobile, but no-go for a phone.
We are talking about 1..2W max for decoding, so such CPU may not be suitable for a phone.
Other SoC makers will try to get a share of the production capacity of hopefully 60000 wafers/month,
and these may have to wait..Besides, I am not against VVC, only my hope is measured against reality.

[ksec]

Unfanned 8W power consumption, fanned 17-30W, thanks TSMC.
This is a big power saving achievement for any desktop and notebook segment.

So one may call that mobile, but no-go for a phone.
We are talking about 1..2W max for decoding, so such CPU may not be suitable for a phone.
Other SoC makers will try to get a share of the production capacity of hopefully 60000 wafers/month,
and these may have to wait..Besides, I am not against VVC, only my hope is measured against reality.

Where did the 1-2W VVC Decoding came from?

[Emulgator]

Requirement for recent mobile phone energy plans, not concerning VVC in particular, just any decoding consumption has to pass through that needle's eye.
The rest of the phone wants to eat too. Any CPU/GPU load, display brightness, wifi 5G, audio processing & amplification, vibration, AI...

An iPhone 15 is reported to consume 4,5W in total while gaming:
https://www.notebookcheck.net/Severe-Apple-iPhone-15-Pro-Max-thermal-throttling-reported-as-A17-Pro-appears-to-push-surface-temperatures-to-48-C-during-gaming.753143.0.html
BTW, I am not with the pseudo-critical tone, 4,5W for gaming is an achievement, given the processing complexity of the task.
and +48°C are to be expected to be fair, I only linked to show the wattage.
Lets keep those 4W as a ballpark figure of a mobile phone's max. total consumption

A Huawei P30Pro (Kirin980) may eat 3,5W while shooting AVC, a P40Pro+ (Kirin990) 4,0W while shooting HEVC
the 4200mAh, 3,7V accu yields 15Wh, 18hrs playback tell: maybe 1,2W on playback.
If any new codec wants to spend just double watts, then let's imagine the bashing reports:
"Ouch, The new uphone only lasts 50% the time. What went wrong ?"

The larger available mobile phone batteries are around 4000..4200mAh, with 3,7V you can calculate 14,8Wh,
and they can not be made any bigger.

[hajj_3]

November 21, 2023 – MainConcept, the leading provider of video and audio codecs, has announced the latest version of its real-time encoding application for OTT and TV broadcasting workflows, Live Encoder 3.4. It comes with two powerful additions, support for VVC/H.266 and MPEG-5 LCEVC and aims to transform the way in which broadcasters and OTT content providers distribute live video, streamline workflows, and elevate the overall viewing experience.

https://www.mainconcept.com/mainconcept-launches-live-encoder-3.4-with-vvc-and-lcevc

[benwaggoner]

Requirement for recent mobile phone energy plans, not concerning VVC in particular, just any decoding consumption has to pass through that needle's eye.
The rest of the phone wants to eat too. Any CPU/GPU load, display brightness, wifi 5G, audio processing & amplification, vibration, AI..
Sure. But from folks I've talked to, the VVC decoder requires less mm^2 of a SoC than AV1, and draws a little less power as well.

[Emulgator]

Compared to AV1, I concur.

[benwaggoner]

Compared to AV1, I concur.
MPEG has been pretty good at keeping the decoder complexity increase generation to generation down to about 2x. Which, given Moore's Law, makes each generation quite a bit cheaper to add to a SoC at launch.

[birdie]

A full native VVC decoder for ffmpeg (most likely GIT or version 6.1) has been posted (https://patchwork.ffmpeg.org/project/ffmpeg/patch/TYSPR06MB6433294423DE121C79F33D4AAA88A@TYSPR06MB6433.apcprd06.prod.outlook.com/).

I will test it next week when/if I make it home.

vvc decoder plug-in to avcodec.
split frames into slices/tiles and send them to vvc_thread for further decoding
reorder and wait for the frame decoding to be done and output the frame

Features:
+ Support I, P, B frames
+ Support 8/10/12 bits, chroma 400, 420, 422, and 444 and range extension
+ Support VVC new tools like MIP, CCLM, AFFINE, GPM, DMVR, PROF, BDOF, LMCS, ALF
+ 295 conformace clips passed
- Not support RPR, IBC, PALETTE, and other minor features yet

Performance:
Asm optimizations still working in progress. please check
https://github.com/ffvvc/FFmpeg/wiki#performance-data for the latest

Contributors(based on code merge order):
Nuo Mi <nuomi2021 gmail.com>
Xu Mu <toxumu outlook.com>
frankplow <post frankplowman.com>
Shaun Loo <shaunloo10 gmail.com>

vvdec by Fraunhofer HHI is quite heavy. I've recently encoded a 1024x576@30 video (here's a sample (https://mega.nz/file/PgNiwLzA#pIRNACUVTpD1xcbWlo0Il4p_vv2E5nE4l5c-1Y5_hno) or full video (https://mega.nz/file/C10zmRxC#61UNJIkdaLIbAYrbGy34OrF_iyukqAaL6Vj_hGp--Rc) for anyone who's interested) using preset slow and q=31 and my 7840HS consumes over 20W (!) decoding it which is just staggering. I'm pretty sure vvdec will fail to decode 1080p videos in real time on my Zen 4 CPU.

[FranceBB]

That's an amazing news! The moment FFMpeg gets an internal decoder, it spreads everywhere (LAV, VLC, MPV, LWLibav, FFVideo etc) so this is definitely welcome.
About VVDec, I remember having a conversation with Ben a while ago (several months actually) about decoding H.266 and I haven't tried it recently to see if there was any progress, but from what you're saying everything stayed the same.
If that's the case, although it might be "ok-ish" for desktop CPUs, it's definitely not for laptops and definitely not for smartphones as they're gonna need hardware decoding.
For comparison, back when I was talking to Ben about this, I tried a 50p realtime decoding of a FULL HD video on my 8c/16th Intel Xeon and I'm sure that if it had a face it would have looked at me and said "haha nice try bro". xD (TL;DR it couldn't).
The fact that ffvvc reports 200+ fps on a FULL HD 60p clip on a puny 8c/16th i7 like the 12700K shows a really great performance advantage compared to VVDec.
I mean, if that's the case, then software decoding might actually become a thing for H.266 VVC and that would definitely drive adoption 'cause after that all we need is x266 (hopefully also coming in 2024) and then we're ready to go.
That being said, I don't wanna be too harsh on Fraunhofer given that it has allowed me to test and try and test and try over and over again using VVEnc and VVDec, including working on some interesting samples last year, so, although we all knew it wasn't gonna make it into production, hats off to Fraunhofer for providing something better than the default unusable (i.e too slow) VTM reference encoder.

[Jamaika]

https://github.com/ffvvc/FFmpeg/commit/6e8865cea286c4373d60234f6963ce618b81f9fd
Modest VVC profile
const AVProfile ff_vvc_profiles[] = {
{ AV_PROFILE_VVC_MAIN, "Main" },
{ AV_PROFILE_VVC_MAIN_10, "Main 10" },
{ AV_PROFILE_VVC_MAIN_10_444, "Main 10 4:4:4" },
{ AV_PROFILE_UNKNOWN },
};
It plays great on very old computer only VVC 10bit. Bad movie rewind.
Stream #0:0: Video: vvc (Main), yuv420p10le(tv), 1024x576, 25 fps, 30 tbr, 1200k tbn
[vvc @ 000001784014c7c0] Duplicate POC in a sequence: 31.0B f=0/0
[vvc @ 000001784014c7c0] Error parsing NAL unit #3.

Stream #0:0: Video: vvc (Main), yuv420p(tv), 1920x1080, 25 fps, 29.97 tbr, 1200k tbn
[vvc @ 000001c476f1e8f0] frame 13, P( 29, 13) failed with -1094995529

I understand that uvg266 is a thing of the past. It isn't accepted.

[benwaggoner]

VVC is well designed for efficient decoding - factored well for good parallelism and SIMD. I've heard several experts estimate that a software decoder of equivalent optimization for VVC would give a higher decode fps than AV1. Real-world, AV1 encoders are several years ahead in performance optimizations, of course. But VVC should be at least as viable as AV1 for SW decode on phones etcetera.

[v0lt]

FFmpeg seems to have added a VVC decoder (https://github.com/FFmpeg/FFmpeg/commit/301ed950d1c3c500d0c2eee8472587dc5e691c04)

[birdie]

FFmpeg seems to have added a VVC decoder (https://github.com/FFmpeg/FFmpeg/commit/301ed950d1c3c500d0c2eee8472587dc5e691c04)

Hooray! Finally! I'm now compiling it.

The original git repo (https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/301ed950d1c3c500d0c2eee8472587dc5e691c04) is still where it used to be.

[birdie]

The native VVC decoder in ffmpeg is simply amazing! It's at least twice as fast/efficient as vvdec.

Unfortunately it doesn't (https://github.com/ffvvc/FFmpeg/issues/181) yet play some pretty standard VVC videos.

[ShortKatz]

I've build a version of Handbrake with the current FFmpeg and I was able to open one vvc file out of my vvc video sample collection. So it indeed does not play some pretty standard VVC videos.

[Jamaika]

The native VVC decoder in ffmpeg is simply amazing! It's at least twice as fast/efficient as vvdec.

Unfortunately it doesn't (https://github.com/ffvvc/FFmpeg/issues/181) yet play some pretty standard VVC videos.

He doesn't like mp4 because there is no mp4 plugin.
He doesn't like mp4 because there is no mp4 plugin.
Input #0, vvc, from 'NovosobornayaSquare_1920x1080_track1.vvc':/0
Duration: N/A, bitrate: N/A
Stream #0:0: Video: vvc (Main), yuv420p(tv), 1920x1080, 25 fps, 59.94 tbr, 1200k tbn
[ffplay_buffer @ 0000021583a827f0] filter context - w: 1920 h: 1080 fmt: 0 csp: unknown range: unknown, incoming frame - w: 1920 h: 1080 fmt: 0 csp: unknown range: tv pts_time: NOPTS
[ffplay_buffer @ 0000021583a827f0] Changing video frame properties on the fly is not supported by all filters.
[ffplay_buffer @ 0000021583a827f0] filter context - w: 1920 h: 1080 fmt: 0 csp: unknown range: unknown, incoming frame - w: 1920 h: 1080 fmt: 0 csp: unknown range: tv pts_time: NOPTS

Poorly created mp4 container. Incorrect framerate.
Video
ID : 1
Format : VVC
Codec ID : vvc1
Codec ID/Info : Versatile Video Coding
Duration : 10 s 0 ms
Bit rate : 4 008 kb/s
Maximum bit rate : 5 196 kb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 60.000 FPS
Bits/(Pixel*Frame) : 0.032
Stream size : 4.78 MiB (100%)
Title : bin@GPAC2.3-DEV-rev550-gec2a3776-master
Encoded date : 2023-09-28 14:25:08 UTC
Tagged date : 2023-09-28 14:25:08 UTC
mdhd_Duration : 10067
Codec configuration box : vvcC

Idea:
mp4box.exe -raw 1 NovosobornayaSquare_1920x1080.mp4
ffmpeg_avx.exe -i NovosobornayaSquare_1920x1080_track1.vvc -c:v copy NovosobornayaSquare_1920x1080_track1.mp4 (Jamaika codec)
Output #0, mp4, to 'NovosobornayaSquare_1920x1080_track1.mp4':
Metadata:
encoder : Lavf60.20.100
Stream #0:0: Video: vvc (Main) (vvc1 / 0x31637676), yuv420p(tv), 1920x1080, q=2-31, 25 fps, 59.94 tbr, 1200k tbn
Press [q] to stop, [?] for help
[mp4 @ 00000264b8266c10] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
[mp4 @ 00000264b8266c10] pts has no value
Last message repeated 336 times
[mp4 @ 00000264b8266c10] pts has no valued=N/A
Last message repeated 262 times


It's already playing something. :)

[FranceBB]

It's at least twice as fast/efficient as vvdec.

I've been testing it too but although it does appear to be faster, it's not quite twice as fast compared to VVDec.
I'm currently sick at home and confined to bed (seasonal flu), but I'll make some more tests once I get better.
Just to be sure, do you have a particular file you tested it on where decoding was twice as fast? I wanna try it on my 8c/16th Xeon to see if the results you're getting are hardware dependent.

[birdie]

I've been testing it too but although it does appear to be faster, it's not quite twice as fast compared to VVDec.
I'm currently sick at home and confined to bed (seasonal flu), but I'll make some more tests once I get better.
Just to be sure, do you have a particular file you tested it on where decoding was twice as fast? I wanna try it on my 8c/16th Xeon to see if the results you're getting are hardware dependent.

The situation is quite complicated.

vvdec by itself is several times faster than the native VVC decoder in ffmpeg however the patch to integrate vvcdec into ffmpeg results in its performance advantage disappearing and getting even worse than native which sounds like the patch does something wrong.

I've described everything here (https://github.com/fraunhoferhhi/vvdec/issues/158#issuecomment-1875915496).

[FranceBB]

Ahhhhhh! Gotcha! Makes sense now.
Well I didn't know it was faster 'cause I always used it via the FFMpeg integration. This is interesting.
I think I have to redo all the tests with the native VVDec now and report back here, I'll keep you guys posted.

[hajj_3]

vvc datacentre decoder ip block: https://www.verisilicon.com/en/IPPortfolio/HantroVC9800D

it supports lots of other codecs too.

[Blue_MiSfit]

There's no mention of VVC on those marketing pages :)

[hajj_3]

There's no mention of VVC on those marketing pages :)

there is on the decoder one. i mis-read the encoder page though.

[v0lt]

Nightly builds of MPC-BE (https://github.com/Aleksoid1978/MPC-BE/wiki/Nightly-builds) can decode some VVC videos in MP4 container. There is also support for MPEG-TS and RAW, but this is more problematic.

[birdie]

vvdec has been updated to make it more than three times more energy (https://github.com/fraunhoferhhi/vvdec/issues/158#issuecomment-1898655263) efficient when it's being used as a decoding backend for ffmpeg (and other libs/apps using it) thanks to my input :-)

[benwaggoner]

vvdec has been updated to make it more than three times more energy (https://github.com/fraunhoferhhi/vvdec/issues/158#issuecomment-1898655263) efficient when it's being used as a decoding backend for ffmpeg (and other libs/apps using it) thanks to my input :-)
Well done!

[FranceBB]

The following inputs have been produced from TX Ready XDCAM-50 files:

Sample 1: ColorBars FULL HD H266 YV12 BT709 SDR 10bit.ts
Sample 2: Chicago Fire FULL HD H266 Main10 12Mbits 25p YV12 BT709 SDR 10bit AC3 2ch 48000Hz.ts
Sample 3: Judas and the Black Messiah SD H266 Main10 3Mbits 25p YV12 BT601 SDR 10bit AC3 2ch 48000Hz.ts
Sample 4: The Creator FULL HD H266 Main10 12Mbits 25p YV12 BT709 SDR 10bit AC3 2ch 48000Hz.ts

The decoding has been carried out using the following hardware:

A) Intel Xeon E5-2637 v4 3.50GHz dual socket 8c/16th, 64GB RAM
B) Intel i7 5930K 3.50GHz single socket 6c/12th 32GB RAM
C) Intel Xeon Gold 6238R 2.20GHz dual socket 56c/112th 128GB RAM

The tests have been conducted both using FFMpeg's new decoder and Fraunhofer's VVDec standalone decoder (i.e WITHOUT using the FFMpeg integration patch).

Colorbars have been skipped in the benchmark decoding test due to the fact that it's quite literally the same frame repeated all over again and it would yield no significant speed outcome.

Now, on to the FFMpeg decoder results:

Intel Xeon E5-2637 v4 3.50GHz dual socket 8c/16th, 64GB RAM

Sample 2: Chicago Fire FULL HD H266 Main10 12Mbits 25p YV12 BT709 SDR 10bit AC3 2ch 48000Hz.ts

CPU constantly at around 89-100%

fps= 35


Sample 3: Judas and the Black Messiah SD H266 Main10 3Mbits 25p YV12 BT601 SDR 10bit AC3 2ch 48000Hz.ts

CPU oscillated between 78% and 93% without ever touching full 100%.


fps=194


Sample 4: The Creator FULL HD H266 Main10 12Mbits 25p YV12 BT709 SDR 10bit AC3 2ch 48000Hz.ts

CPU oscillated between 41% to 76% without ever touching full 100%.

fps= 24


Intel i7 5930K 3.50GHz single socket 6c/12th 32GB RAM

Sample 2: Chicago Fire FULL HD H266 Main10 12Mbits 25p YV12 BT709 SDR 10bit AC3 2ch 48000Hz.ts

CPU steadily at 100%

fps= 34

Sample 3: Judas and the Black Messiah SD H266 Main10 3Mbits 25p YV12 BT601 SDR 10bit AC3 2ch 48000Hz.ts

CPU steadily at 100%

fps=193

Sample 4: The Creator FULL HD H266 Main10 12Mbits 25p YV12 BT709 SDR 10bit AC3 2ch 48000Hz.ts

CPU oscillated between 65% and 93% with occasional very rare spikes to 100%

fps= 28


Intel Xeon Gold 6238R 2.20GHz dual socket 56c/112th 128GB RAM

Sample 2: Chicago Fire FULL HD H266 Main10 12Mbits 25p YV12 BT709 SDR 10bit AC3 2ch 48000Hz.ts

CPU steadily at 23% overall with cores being used on one single socket

fps= 44

Sample 3: Judas and the Black Messiah SD H266 Main10 3Mbits 25p YV12 BT601 SDR 10bit AC3 2ch 48000Hz.ts

CPU steadily at 13% overall with cores being used on one single socket

fps=249

Sample 4: The Creator FULL HD H266 Main10 12Mbits 25p YV12 BT709 SDR 10bit AC3 2ch 48000Hz.ts

CPU steadily at 18% overall with cores being used on one single socket

fps= 26



And now on to the VVDec results:

Intel Xeon E5-2637 v4 3.50GHz dual socket 8c/16th, 64GB RAM

Sample 2: Chicago Fire FULL HD H266 Main10 12Mbits 25p YV12 BT709 SDR 10bit AC3 2ch 48000Hz.ts

CPU steadily at 100%

fps=111

Sample 3: Judas and the Black Messiah SD H266 Main10 3Mbits 25p YV12 BT601 SDR 10bit AC3 2ch 48000Hz.ts

CPU steadily at 100%

fps=618

Sample 4: The Creator FULL HD H266 Main10 12Mbits 25p YV12 BT709 SDR 10bit AC3 2ch 48000Hz.ts

CPU steadily at 100%

fps=119


Intel i7 5930K 3.50GHz single socket 6c/12th 32GB RAM

Sample 2: Chicago Fire FULL HD H266 Main10 12Mbits 25p YV12 BT709 SDR 10bit AC3 2ch 48000Hz.ts

CPU steadily at 100%

fps=108

Sample 3: Judas and the Black Messiah SD H266 Main10 3Mbits 25p YV12 BT601 SDR 10bit AC3 2ch 48000Hz.ts

CPU steadily at 100%

fps=634

Sample 4: The Creator FULL HD H266 Main10 12Mbits 25p YV12 BT709 SDR 10bit AC3 2ch 48000Hz.ts

CPU steadily at 100%

fps=115


Intel Xeon Gold 6238R 2.20GHz dual socket 56c/112th 128GB RAM

Sample 2: Chicago Fire FULL HD H266 Main10 12Mbits 25p YV12 BT709 SDR 10bit AC3 2ch 48000Hz.ts

CPU steadily at 65% on one single socket

fps=226

Sample 3: Judas and the Black Messiah SD H266 Main10 3Mbits 25p YV12 BT601 SDR 10bit AC3 2ch 48000Hz.ts


CPU steadily at 55% on one single socket

fps=722

Sample 4: The Creator FULL HD H266 Main10 12Mbits 25p YV12 BT709 SDR 10bit AC3 2ch 48000Hz.ts

CPU steadily at 66% on one single socket

fps=211


This shows that not only VVDec is more optimized and makes use of the CPU resources in a better way (being able to scale even with CPUs that have a lot of cores, although not quite in every dual socket configuration) but the fps results tell the whole story, it's just faster. Before I made some claims about libav (i.e FFMpeg) being faster, however that was truly a mistake in my testing as it was just me not using VVDec directly but rather through an old unapproved patch via FFMpeg which was totally not optimized. Now that I compared libav via FFMpeg and VVDec using the native Fraunhofer executable, the whole story is completely different and VVDec appears to be miles ahead.
On top of that, upon further testing, I had to throw away some samples as they reported the following error while trying to decode them with libav/FFMpeg:

frame 78, P( 14, 1) failed with -1163346256
Intra Block CopyIntra Block Copy is not implemented.
your file has a feature which has not been implemented.
Decoding error: Not yet implemented in FFmpeg, patches welcome

yet, VVDec managed to decode even those files without the blink of an eye.
Nonetheless, here are the results of my tests:

https://i.imgur.com/6X3XTIm.png
https://i.imgur.com/3gvATNZ.png
https://i.imgur.com/M031f2C.png


As the graph show, VVDec seems to be making a much better use of the resources available and this is even more obvious when it's used on the "big boys" like on a Dual Intel Xeon Gold 6238R 2.20GHz made of a dual socket configuration with 56c/112th.

FFMpeg Libav:
https://i.imgur.com/vOidOg7.png

VVDec:
https://i.imgur.com/QXcuJun.png


The only thing I would "argue" to VVDec is that it's only making use of a single socket rather than spreading the decoding across both sockets, but still, 211fps on a FULL HD 10bit is more than enough. Next on the list for my tests are gonna be the UHD encodes to see whether we can get realtime software decoding or not.
I have little to no expectations for Libav in terms of realtime decoding, but let's see if VVDec can pull it off.
For now, though, FULL HD decoding at playback time is more than achieved by both Libav (FFMpeg) and VVDec even on very modest hardware like the old Intel i7 5930K, which means that at least for resolutions up to FULL HD and framerates not exceeding 25fps we're pretty much covered and, incidentally, 23.976p and 25p contents make up the overwhelming majority of the contents out there, which means that this is a very good sign.

https://i.imgur.com/vKG9ZXL.png


In case you're wondering, all samples are available here (link valid for 7 days): https://we.tl/t-ztfQeVjxNP


Cheers,
Frank

[ShortKatz]

On top of that, upon further testing, I had to throw away some samples as they reported the following error while trying to decode them with libav/FFMpeg:

frame 78, P( 14, 1) failed with -1163346256
Intra Block CopyIntra Block Copy is not implemented.
your file has a feature which has not been implemented.
Decoding error: Not yet implemented in FFmpeg, patches welcome

You don't need to throw away this samples. It's just, that not all features are currently implemented in libav/FFMpeg VVC decoder, intra block copy is not supported yet.
https://github.com/ffvvc/FFmpeg/issues/181#issuecomment-1882369403

[FranceBB]

Yes, I know, I mean I threw them away from the benchmarks :P

Anyway, about Intra Block Copy, I've got a reply from Nuomi


IBC is not supported yet.
We are busy pushing asm code upstream.
We're gonna work on it once the ALF ASM code is upstreamed.

So it will be implemented, just not right now as they're busy.
Still, I don't quite understand why they're writing assembly optimizations at this stage.
I think a decoder should first support all features in plain C and then, only once that's done, comes the time to optimise by writing the intrinsics in assembly...

[birdie]

Yes, I know, I mean I threw them away from the benchmarks :P

Anyway, about Intra Block Copy, I've got a reply from Nuomi



So it will be implemented, just not right now as they're busy.
Still, I don't quite understand why they're writing assembly optimizations at this stage.
I think a decoder should first support all features in plain C and then, only once that's done, comes the time to optimise by writing the intrinsics in assembly...

The patch to add IBC support is all C: https://github.com/ffvvc/FFmpeg/pull/169/files

They are pushing ASM routines for different stuff which is already known to work well.

[FranceBB]

The patch to add IBC support is all C: https://github.com/ffvvc/FFmpeg/pull/169/files

They are pushing ASM routines for different stuff which is already known to work well.

Ohh! Gotcha! Makes sense.

[ShortKatz]

Yes, I know, I mean I threw them away from the benchmarks :P

Haha, OK, then this was just a misunderstanding. :-D

[ShortKatz]

Now support for mp4 and ts was added. Things are getting exciting. :-)

[FranceBB]

Now support for mp4 and ts was added. Things are getting exciting. :-)

Yep, very exciting! :D
I downloaded and compiled the latest master a few minutes ago and I tried to remux an SD H.266 stream in .ts and it worked:


ffmpeg.exe -hide_banner -i "A:\MEDIA\temp\raw_video.ts" -i "A:\MEDIA\temp\raw_audio.ac3" -map 0:0 -map 1:0 -c:v copy -c:a copy -f mpegts -metadata provider_name="Test" -metadata service_provider="Test" -metadata service_name="Test" -mpegts_original_network_id 0x1122 -mpegts_transport_stream_id 0x3344 -mpegts_service_id 0x5566 -mpegts_pmt_start_pid 0x1500 -mpegts_start_pid 0x150 -mpegts_service_type "digital_tv" -mpegts_flags "resend_headers" -y "A:\MEDIA\temp\final_output.ts"



Sample: https://we.tl/t-VEoyak4661

Looks just fine and decodable:
https://i.imgur.com/lbjCOMV.png

[FranceBB]

Also with the latest version of Mediainfo, 24.01, H.266 VVC is now detected in .ts!

From the changelog:

- MPEG-TS: detection of VVC

and indeed:


General
ID : 13124 (0x3344)
Complete name : A:\MEDIA\temp\Colorbars_H266_VVC_Mux_FFMpeg.ts
Format : MPEG-TS
File size : 248 KiB
Duration : 4 s 0 ms
Overall bit rate mode : Variable
Overall bit rate : 473 kb/s

Video
ID : 336 (0x150)
Menu ID : 21862 (0x5566)
Format : VVC
Format/Info : Versatile Video Coding
Codec ID : 51
Duration : 4 s 0 ms
Bit rate : 62.0 kb/s
Stream size : 30.3 KiB (12%)

Audio
ID : 337 (0x151)
Menu ID : 21862 (0x5566)
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Codec ID : 129
Duration : 4 s 64 ms
Bit rate mode : Constant
Bit rate : 384 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossy
Stream size : 190 KiB (77%)
Service kind : Complete Main

Menu
ID : 5376 (0x1500)
Menu ID : 21862 (0x5566)
Format : VVC / AC-3
Duration : 4 s 0 ms
List : 336 (0x150) (VVC) / 337 (0x151) (AC-3)
Service name : Test
Service provider : Test
Service type : digital television

[Jamaika]

I was unable to play the video.
https://github.com/FFmpeg/FFmpeg/commit/f6b7b473d456a6aa1c063c4261b17277e2c70ac0
Are any fixes planned?
https://www.sendspace.com/file/2j1lu3

[FranceBB]

After talking to Jerome (the Mediainfo creator) he said that Mediainfo 24.01 is supposed to be able to detect the Level and Profile, which is not happening for my samples, so I tracked the thing in an issue on GitHub: https://github.com/MediaArea/MediaInfoLib/issues/1960

This is in reference of other people asking support for it (which technically has been introduced already but doesn't seem to be working in all scenarios): https://github.com/MediaArea/MediaInfoLib/issues/1942


EDIT:
Jerome replied. Looks like the FFMpeg ts muxer isn't writing the TS VVC descriptor at all.
More work needs to be done on the FFMpeg side.

So circling back to the "things are getting exciting" statement: yes, but not quite yet... :(

[birdie]

Gain of Grain: A Film Grain Handling Toolchain for VVC-based Open Implementations (https://arxiv.org/pdf/2402.00622.pdf) (PDF).

Adam Wieckowski - Why is your encoder so slow? The curse of next-gen standards (https://www.youtube.com/watch?v=RvXmdJV6Yac) (YouTube): "The talk will combine abstract high level analytics with practical experiences from the development of an optimized encoder for the recent Versatile Video Coding (VVC) standard. While based on a specific codec and implementation, the concepts generalize to a variety of modern standards, including AV1 and HEVC."

[benwaggoner]

So circling back to the "things are getting exciting" statement: yes, but not quite yet... :(
Oh, it is very exciting in the "doing HEVC in 2014" flavor of exciting :sly:.

For those of us who get paid to figure out how to make the impossible merely very difficult, and then hand it off to someone else, at least.

[FranceBB]

Oh, it is very exciting in the "doing HEVC in 2014" flavor of exciting :sly:.


Yeah I remember the days of experimenting back then... It was fun... But that was probably 'cause it was the first new codec after years and years and years of dominance by H.264 and everyone had very high expectations...



For those of us who get paid to figure out how to make the impossible merely very difficult, and then hand it off to someone else, at least.

Lucky... My job nowadays is mostly parsing json from REST API POST calls, reading xml and creating supply chains to make different stuff talk to each other according to the various payloads etc...
I used to encode stuff, to work with production companies, to tweak different encoding parameters, experiment new filters etc... but not any longer...
I die every day one bit at a time... :(

[benwaggoner]

Yeah I remember the days of experimenting back then... It was fun... But that was probably 'cause it was the first new codec after years and years and years of dominance by H.264 and everyone had very high expectations...
Plus "we can do HDR! And UHD at plausible streaming bitrates."


Lucky... My job nowadays is mostly parsing json from REST API POST calls, reading xml and creating supply chains to make different stuff talk to each other according to the various payloads etc...
I used to encode stuff, to work with production companies, to tweak different encoding parameters, experiment new filters etc... but not any longer...
I die every day one bit at a time... :(
I do like my job. Of course, I spend far my time working through issues with unfinished tools with insufficient documentation than I do innovating per se. As always at the bleeding edge, the "hard part" is rarely the actual hard part.

I have dim memories of when encoding could be done with a GUI tool that could preview settings, instead of just having a huge wad of shell scripts I painfully iterate on, annoying myself with my own syntax errors wasting a half day of processing.

By the time something gets easy, someone else is doing it and I'm off on the new impossible thing.

We've got a lot of cool stuff in the industry right now, with VVC, film grain simulation on the cusp of practicality, stereo 3D interest resorting, HDR advertising becoming important, etcetera. And a new wave of object-based and low bitrate audio codecs. All all sorts of exciting ways to use dynamic metadata to help content better adapt to customer context.

[ShortKatz]

Seems ffmpeg plans to hide the new VVC decoder behind an experimental flag.
https://ffmpeg.org//pipermail/ffmpeg-devel/2024-February/321060.html

[FranceBB]

Seems ffmpeg plans to hide the new VVC decoder behind an experimental flag.
https://ffmpeg.org//pipermail/ffmpeg-devel/2024-February/321060.html

Yes I followed the conversation and it looks like that it's because it's not main10 ready.
This means that if you encode a stream that makes use of some encoding tools that are not yet supported in FFVVC it won't decode it, the most important of which is Intra Block Copy. There are other things not yet implemented, although most of them are more "esoteric" like support for 360 videos etc.
Anyway once it's gonna be main10 ready (i.e support the decoding of streams encoded with any property/coding tool that the main10 profile allows) the experimental flag will be dropped.

[ShortKatz]

Thanks for that information to get a better picture.

[Ritsuka]

The main reason for the experimental tag is that it hasn't been tested and fuzzed enough yet, so the code has still a bit of bugs and overflows and whatever security issues C can have that are being fixed.

[birdie]

Yes I followed the conversation and it looks like that it's because it's not main10 ready.
This means that if you encode a stream that makes use of some encoding tools that are not yet supported in FFVVC it won't decode it, the most important of which is Intra Block Copy. There are other things not yet implemented, although most of them are more "esoteric" like support for 360 videos etc.
Anyway once it's gonna be main10 ready (i.e support the decoding of streams encoded with any property/coding tool that the main10 profile allows) the experimental flag will be dropped.

If you'd actually followed the conversation, you wouldn't have said that. It's not about completeness, it's about a ton of C code which needs to be thoroughly verified for bugs:

source 1 (https://ffmpeg.org//pipermail/ffmpeg-devel/2024-February/321109.html):
Author of this patch above is forced to FUZZ this decoder until
experimental flag is removed.

source 2 (https://ffmpeg.org//pipermail/ffmpeg-devel/2024-February/321063.html):
Sure, this isn't saying your incredible work is bad. It's just the reality
that a complex codec needs to be fuzzed heavily otherwise the security
community will report FFmpeg 7.0 has a ton of security issues

[FranceBB]

It's not about completeness, it's about a ton of C code which needs to be thoroughly verified for bugs

I see! Well I didn't mean the mailing list, I meant when one briefly mentioned it at FOSDEM, but anyway gotcha.
Still, it's also not main10 ready.
Anyway, I guess I'll try again with a benchmark after this summer when hopefully all coding tools are gonna be supported and there's gonna be manually written assemblies for everything and see whether it closed the gap with VVDec in the meantime.

Then, as decoders mature, the question remains: will we get x266 too this year? Eheheheh

[benwaggoner]

Then, as decoders mature, the question remains: will we get x266 too this year? Eheheheh
That has certainly been the strong indication. And hopefully x265 3.6, as we approach three years since 3.5 was released.

Hopefully x266 will be able to reuse some of the great ARM optimizations added since 3.5. Master is more than twice as fast as 3.5 on Graviton and Apple Silicon.

VVC is around where x265 was in late 2014, taking over an hour to encode one minute of high quality 2160p24 on then high-end hardware.

[FranceBB]

Nuo Mi just finished working on Intra Block Copy, which was the last coding tool not yet supported by the decoder.
I sent him 3 real life H.266 + AC3 .ts samples using it so that he can test locally and see whether they actually work or not.
If everything goes well, hopefully they're soon gonna be able to merge it upstream.
What does it mean for us?
Well, it means that very soon we're gonna have LWLibavVideoSource() and FFVideoSource() working and able to decode H.266 in Avisynth and VapourSynth! :D
What does it mean for the wider community beyond Avisynth and VapourSynth?
Well, it means it that as soon as it's merged upstream, it will be ported everywhere the likes of MPV, VLC etc and now that the decoder is ready we're quite literally one step away from it finally being adopted.
So, that one will hopefully be sorted soon, which means that if x266 gets released before the end of 2024, give it a few months of refinement/optimization/tests and hopefully 2025 (next year) will finally be the year of the widespread H.266 adoption! :D

[birdie]

Nuo Mi just finished working on Intra Block Copy, which was the last coding tool not yet supported by the decoder.
I sent him 3 real life H.266 + AC3 .ts samples using it so that he can test locally and see whether they actually work or not.
If everything goes well, hopefully they're soon gonna be able to merge it upstream.
What does it mean for us?
Well, it means that very soon we're gonna have LWLibavVideoSource() and FFVideoSource() working and able to decode H.266 in Avisynth and VapourSynth! :D
What does it mean for the wider community beyond Avisynth and VapourSynth?
Well, it means it that as soon as it's merged upstream, it will be ported everywhere the likes of MPV, VLC etc and now that the decoder is ready we're quite literally one step away from it finally being adopted.
So, that one will hopefully be sorted soon, which means that if x266 gets released before the end of 2024, give it a few months of refinement/optimization/tests and hopefully 2025 (next year) will finally be the year of the widespread H.266 adoption! :D

Adoption is a strong word here.

H.265 is nowhere near as ubiquitous as H.264 still is. On the Internet H.265 is basically not used, the scene has also largely ignored it, most smartphones still default to H.264 despite sporting a HW H.265 encoder.

Unless H.266 shows very strong improvements over ... H.264 in 1080p and 4K resolutions, it still has a very strong chance of becoming ... relatively irrelevant and used only by aficionados of modern codecs.

Yeah, both H.265 and H.266 are used or about to be used behind the scenes in production and distribution (e.g. DVB) but end users couldn't care less, and at least for me "adoption" means something which end users are exposed to/dealing with.

And VP9/AV1 both trump H.265 by a wide margin, almost everyone watches youtube daily.

[birdie]

Performance Comparison of VVC, AV1, HEVC and AVC for High Resolutions (https://www.preprints.org/manuscript/202402.0869/v1)

For quality assessment, we used objective metrics, namely Peak Signal-to-Noise Ratio (PSNR), Structural Similarity Index (SSIM) and Video Multi-Method Assessment Fusion (VMAF), which belong to full-reference methods. In terms of the Bjøntegaard-Delta (BD) model, the results showed that H.266/VVC outperforms all other codecs, namely H.264/AVC, H.265/HEVC and AV1, respectively. Averaged bitrate savings were approximately 78% for H.266/VVC, 63% for AV1 and 53% for H.265/HEVC relative to H.264/AVC, 59% for H.266/VVC, 22% for AV1 compared to H.264/AVC and 46% for H.266/VVC relative to AV1, all for 8K resolution. The provided results also varied depending on the used test sequence and resolution – with higher resolution, the effectiveness of newly developed codecs such as H.266/VVC and AV1 is greater. This confirmed the fact that the H.266/VVC and AV1 codecs have been primarily developed for videos at high resolutions such as 8K and/or UHD.

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

[benwaggoner]

Adoption is a strong word here.

H.265 is nowhere near as ubiquitous as H.264 still is. On the Internet H.265 is basically not used, the scene has also largely ignored it, most smartphones still default to H.264 despite sporting a HW H.265 encoder.
By "Internet" do you mean web? There's huge amounts of IP delivered HEVC, including most HDR and UHD premium content. But mostly to devices and apps, not browsers. Web browser support for DRM-protected HEVC is still pretty new, so will only get used for services that can support multiple codecs.

Unless H.266 shows very strong improvements over ... H.264 in 1080p and 4K resolutions, it still has a very strong chance of becoming ... relatively irrelevant and used only by aficionados of modern codecs.
Outside of browser use, premium content is already largely HEVC with some AV1. Companies using those today will certainly be looking towards VVC and AV2 to get further compression efficiency improvements.

Yeah, both H.265 and H.266 are used or about to be used behind the scenes in production and distribution (e.g. DVB) but end users couldn't care less, and at least for me "adoption" means something which end users are exposed to/dealing with.
If an end user cares about what codec is being used, someone has messed up ;). I doubt even 2% of the population knows what codec is being used in any particular thing they're watching.

And VP9/AV1 both trump H.265 by a wide margin, almost everyone watches youtube daily.
There are certainly demographics that watch YouTube daily, which probably overlaps with Doom9 quite a bit. The bulk of people 25+ spend less time on YouTube than subscription streaming, TV, sat, cable, etc. YouTube certainly has a huge number of streams per user per day, but not nearly as many hours per user per day, as lean-back content tends to be longer form.

The user-generated content and the premium content markets are quite different, with a big gap in how much companies are willing to pay per title to encode. The average premium title gets a LOT more views than the average YouTube clip, so the cost of slower encoding and encoding to multiple codecs gets amortized in bandwidth cost savings and customer experience improvement over a LOT more views.

[nevcairiel]

Outside of browser use, premium content is already largely HEVC with some AV1. Companies using those today will certainly be looking towards VVC and AV2 to get further compression efficiency improvements.


Not that soon, as you still need decoders. STBs, Android devices, TVs, VVC adoption hasn't exactly moved in those.

[kurkosdr]

Outside of browser use, premium content is already largely HEVC with some AV1. Companies using those today will certainly be looking towards VVC and AV2 to get further compression efficiency improvements.
My guess is that broadcasters will eventually move to VVC, but when it comes to streaming it's not as clear cut, the companies behind the ISO/ITU formats will have to earn their royalty dollars by offering compression gains that justify the price compared to the AOM codecs. Also, keep in mind streaming isn't fighting for the last Mbps of multiplex space like the broadcasters do (internet speeds tend to get faster as time goes on), so they can make do with a format that's slightly worse as long as it's free. There is a reason Netflix is experimenting with AV1 but not VVC. Things are about to get interesting.

[benwaggoner]

My guess is that broadcasters will eventually move to VVC, but when it comes to streaming it's not as clear cut, the companies behind the ISO/ITU formats will have to earn their royalty dollars by offering compression gains that justify the price compared to the AOM codecs. Also, keep in mind streaming isn't fighting for the last Mbps of multiplex space like the broadcasters do (internet speeds tend to get faster as time goes on), so they can make do with a format that's slightly worse as long as it's free. There is a reason Netflix is experimenting with AV1 but not VVC. Things are about to get interesting.
AV1 hit the market years before VVC, and is actually deployable today. Netflix, Prime Video, YouTube, and others have been delivering it for a while. Nothing about that suggests that Netflix and others aren't experimenting with VVC as well! And will be experimenting with AV2, H.267, and so on, forever.

All indications are that VVC will offer real-world improvements on top of both HEVC and AV1 sufficient to merit evaluation, and potentially good ROI for adoption. The business models to figure out when to introduce another codec for what content are pretty complex. You can imagine that with content that's viewed 1M times, a 30% bitrate reduction it the top UHD HDR bitrate can yield some pretty material bandwidth cost savings.

Also, compression efficiency improvements don't just save money. Better bang for the bit means better quality for bandwidth-constrained customers. Lots of people around the world aren't able to get the top bitrates, particularly on mobile devices.

[birdie]

I wonder what's the uptake for VVC by Qualcomm/Mediatek/Apple/NVIDIA/AMD/Intel going to be. Without a HW decoder, this standard is dead in the water.

Intel Lunar Lake has been rumored to have a HW VVC decoder but that's all I heard. Looks like VVC is at the very least 2-3 years away from a widespread use/adoption and that's only if we're lucky.

[ShortKatz]

I wonder what's the uptake for VVC by Qualcomm/Mediatek/Apple/NVIDIA/AMD/Intel going to be. Without a HW decoder, this standard is dead in the water.


At least Qualcomm is definitely working to implement VVC.
https://www.qualcomm.com/news/onq/2023/07/the-end-of-video-buffering-are-we-there-yet
https://www.qualcomm.com/news/onq/2023/08/the-unparalleled-value-of-qualcomms-video-codec-and-wi-fi-inventions

[kurkosdr]

All indications are that VVC will offer real-world improvements on top of both HEVC and AV1 sufficient to merit evaluation, and potentially good ROI for adoption. The business models to figure out when to introduce another codec for what content are pretty complex. You can imagine that with content that's viewed 1M times, a 30% bitrate reduction it the top UHD HDR bitrate can yield some pretty material bandwidth cost savings.

Also, compression efficiency improvements don't just save money. Better bang for the bit means better quality for bandwidth-constrained customers. Lots of people around the world aren't able to get the top bitrates, particularly on mobile devices.
AOM will not sit still waiting for VVC to catch on, AV2 is already under development, and unlike VVC, it can be implemented at no cost (no royalties) by utilizing GPU shaders and existing decoding hardware (exposed nicely by the driver as "hardware acceleration").

This is why things are about to get interesting: AOM's strategy to release codecs "mid-cycle" of ISO/ITU's release schedule means AV2 will compete with VVC, not ECM.

[birdie]

AOM will not sit still waiting for VVC to catch on, AV2 is already under development, and unlike VVC, it can be implemented at no cost (no royalties) by utilizing GPU shaders and existing decoding hardware (exposed nicely by the driver as "hardware acceleration").

This is why things are about to get interesting: AOM's strategy to release codecs "mid-cycle" of ISO/ITU's release schedule means AV2 will compete with VVC, not ECM.

Not a single widespread video codec has worked this way, suddenly AV2 will be capable of running off shaders. Yeah, really.

[kurkosdr]

Not a single widespread video codec has worked this way, suddenly AV2 will be capable of running off shaders. Yeah, really.
AMD had done it in the past, and anyway, hardware support can be added without an additional royalty expense. That alone is the reason AV1 was a thing in 2022 but VVC is not a thing in 2024, despite those two being 2 years apart.

[birdie]

AMD had done it in the past, and anyway, hardware support can be added without an additional royalty expense. That alone is the reason AV1 was a thing in 2022 but VVC is not a thing in 2024, despite those two being 2 years apart.

AV1 is not a thing in 2024.

1) Not a single midrange mobile Qualcomm SoC supports it. MediaTek fairs better, see below.
2) People nowadays rarely upgrade PCs, so it will take up to a decade to upgrade the entire PC fleet (2 billion devices) for it to support HW AV1 decoding.
3) The vast majority of TV sets presently sold lack a HW AV1 decoder. I bought a brand new 55" smart LG smart TV from their 2023 lineup for my parents six months ago and it doesn't support HW AV1 decoding, nor it cannot decode it in software (too feeble for that).

Overall the vast majority of consumer devices cannot play it effectively or at all.

This is a not a H.266 vs. AV1 topic. People here discuss H.266/VVC. I understand you're enamored by the AV1 codec which Google generously donated to the community but you could advertise it somewhere else. Thanks.

Edit: MediaTek Dimensity 8200 SoC (https://www.mediatek.com/products/smartphone-2/mediatek-dimensity-8200) indeed supports HW AV1 decoding (kudos to them), but there's nothing from Qualcomm. It only supports it in premium Snapdragon 8 Gen 2/3 SoCs.

Apple only has iPhone 15 Pro/Pro Max which support it.

[kurkosdr]

AV1 is not a thing in 2024.

1) Not a single midrange mobile Qualcomm SoC supports it. MediaTek fairs better, see below.
2) People nowadays rarely upgrade PCs, so it will take up to a decade to upgrade the entire PC fleet (2 billion devices) for it to support HW AV1 decoding.
3) The vast majority of TV sets presently sold lack a HW AV1 decoder. I bought a brand new 55" smart LG smart TV from their 2023 lineup for my parents six months ago and it doesn't support HW AV1 decoding, nor it cannot decode it in software (too feeble for that).

Overall the vast majority of consumer devices cannot play it effectively or at all.

This is a not a H.266 vs. AV1 topic. People here discuss H.266/VVC. I understand you're enamored by the AV1 codec which Google generously donated to the community but you could advertise it somewhere else. Thanks.

Edit: MediaTek Dimensity 8200 SoC (https://www.mediatek.com/products/smartphone-2/mediatek-dimensity-8200) indeed supports HW AV1 decoding (kudos to them), but there's nothing from Qualcomm. It only supports it in premium Snapdragon 8 Gen 2/3 SoCs.

Apple only has iPhone 15 Pro/Pro Max which support it.
Well, at least AV1 has been present in PCs sold since 2022 (RTX 30 Series, most AMD RX 6000 series, and GPUs in the intel 13th Gen CPUs), and as you correctly say it's also supported by SoCs for high-end smartphones, so streaming services can already see gains by encoding to AV1. Where is VVC decoding support 2 years later? Nowhere except the 8K UHD TV niche.

That said, I do think VVC will eventually make its way to broadcasting, so TVs will eventually start supporting for it, but by then AV2 will also be a thing with hardware decoders available (and AV1 pretty widely supported by then). And that's why things are about to get interesting.

[Tiramisu]

For what it's worth Mediatek Pentonic Series (https://www.mediatek.com/products/digital-tv/mediatek-pentonic-700) already support VVC decoding and are currently being used in some Hisense consumer TVs. Unfortunately I cannot link any sources better than this Youtube video (https://youtu.be/x07w3xGJILQ?si=1PrFFr7mGEWKlu87&t=61) because I am unable to find other reputable sources that clearly mention the CPU being used.

[birdie]

For what it's worth Mediatek Pentonic Series (https://www.mediatek.com/products/digital-tv/mediatek-pentonic-700) already support VVC decoding and are currently being used in some Hisense consumer TVs. Unfortunately I cannot link any sources better than this Youtube video (https://youtu.be/x07w3xGJILQ?si=1PrFFr7mGEWKlu87&t=61) because I am unable to find other reputable sources that clearly mention the CPU being used.

That's very old news, https://en.wikipedia.org/wiki/Versatile_Video_Coding#Hardware

SoCs have been available for many months already, but TV sets not so much.

[birdie]

H.266 IBC support was merged (https://git.ffmpeg.org/gitweb/ffmpeg.git?a=search&h=HEAD&st=commit&s=VVC) into ffmpeg yesterday along with a ton of new fixes. Hooray!

[v0lt]

H.266 IBC support was merged (https://git.ffmpeg.org/gitweb/ffmpeg.git?a=search&h=HEAD&st=commit&s=VVC) into ffmpeg yesterday along with a ton of new fixes. Hooray!
MPC-BE 1.6.11.164 (https://github.com/qwerttvv/Player/releases) with updated ffmpeg.

[benwaggoner]

H.266 IBC support was merged (https://git.ffmpeg.org/gitweb/ffmpeg.git?a=search&h=HEAD&st=commit&s=VVC) into ffmpeg yesterday along with a ton of new fixes. Hooray!
Was there something specifically challenging about IBC that caused it to be implemented last?

[ShortKatz]

H.266 IBC support was merged (https://git.ffmpeg.org/gitweb/ffmpeg.git?a=search&h=HEAD&st=commit&s=VVC) into ffmpeg yesterday along with a ton of new fixes. Hooray!

This IBC fix seems still needed:
https://github.com/ffvvc/FFmpeg/pull/199/commits/1f9064a3523215da0683d6d2f948cc5db14528fa

[LigH]

New uploads: [Windows][GCC 13.2.0][64 bit]

VTM Encoder/Decoder Version 22.0 (https://www.mediafire.com/file/bz6f6fmdj6d9kj3/VTM_22.0_463b869bd.7z/file) 463b869bd

Fraunhofer VVC Encoder ver. 1.11.0 (https://www.mediafire.com/file/oq2d7vkpk8f2m3h/vvenc_1.11.0-9c1d567.7z/file) 9c1d567

Fraunhofer VVC Decoder ver. 2.2.0 (https://www.mediafire.com/file/h9g240hcf8spgq9/vvdec_2.2.0-ada7270.7z/file) ada7270

[FranceBB]

Thanks for the new, updated builds. I stopped using VTM a long time ago, but I'll happily take VVEnc and VVDec ;)

[FranceBB]

H.266 VVC has entered the evaluation phase for ATSC 3.0, which means that ATSC members will have to vote on that. It is difficult to predict exactly when the membership might vote to make it part of the standard, but the candidate standard period is typically less than a year, so just a few months. Given that DVB has already accepted it, chances are that it might get approved by the end of the year. :)

[birdie]

The scene has started experimenting with VVC. Won't post a link but you can easily Google it up: Oppenheimer (2023) IMAX 2160p UHD HDR BluRay VVenC H.266 VVC AAC 5.1 [RAV1NE]

NOTE 1: The first 3-hour, 4K HDR feature length movie encoded in VVC!
NOTE 2: No CPU cycles were "wasted" since this was encoded on a VPS with AVX2 SIMD, which did not affect my regular encode workflow
NOTE 3: This took 35 DAYS to encode, see VVenC log dump below.
NOTE 4: FFmpeg was used for initial for initial muxing of the raw 266 bitstream into mp4 to preserve HDR metadata, then muxed audio+subtitle with MP4Box
NOTE 5: AAC was preferred over USAC for compatibility reasons and will not change until something drastic happens, qaac with TVBR is used for the best high-bitrate audio quality as possible (over FDK/FhG).
NOTE 6: Special """"thanks"""" to the folks over at Doronime for calling this fun benchmark.. "useless" :trollhq:

===================[ TECHNICAL DETAILS ]=====================



Size: 7.23GB
Tools used: FFmpeg, MP4Box, MP4 Tag Editor, qaac
Encoder settings: VVenC, the Fraunhofer H.266/VVC Encoder, version 1.9.1 [Linux][GCC 11.4.0][64 bit][SIMD=AVX2] (GIT, Commit 40dadd1) | -i - --y4m -v 4 --preset medium -q 23 --qpa off --hdr pq_2020 --tiles 2x1 -c yuv420_10

Video: H.266 / VVC | 3840x2160 - 10bit - 23.976 fps - 5280 kbit/s - HDR10 (BT.2020 PQ)
Subtitle(s): English SDH (SRT)

Audio:
AAC 5.1 - 454kbit/s - ?? English


Source: 2160p REMUX

[Atak_Snajpera]

Comparision with x265 with the same bitrate would be great.

[ksec]

The scene has started experimenting with VVC. Won't post a link but you can easily Google it up: Oppenheimer (2023) IMAX 2160p UHD HDR BluRay VVenC H.266 VVC AAC 5.1 [RAV1NE]

Off Topic on Doom9 but I am happy to see appreciation of AAC-LC. The Scene, people who are actually doing lots of encoding ( I want to say professional but I guess that is not the right word ) has made the right choice. It is just unfortunate most people dont get this and as AAC-LC is now fully patent free.

For Video, 35 days to encode. I guess it is a low end VPS?

[birdie]

That encode is broken anyways, A/V are not synchronized at least for me.

And ffmpeg's built-in VVC decoder cannot handle it. It needs a ton of optimizations.

[benwaggoner]

Off Topic on Doom9 but I am happy to see appreciation of AAC-LC. The Scene, people who are actually doing lots of encoding ( I want to say professional but I guess that is not the right word ) has made the right choice. It is just unfortunate most people dont get this and as AAC-LC is now fully patent free.

For Video, 35 days to encode. I guess it is a low end VPS?
What were people doing instead of AAC-LC?

[FranceBB]

What were people doing instead of AAC-LC?

They mentioned USAC, so I guess xHE-AAC, Netflix style, instead of a standard AAC-LC?
I don't know, though, just a wild guess, but for what it's worth I'm also a supporter of the good old AAC-LC.




Side note:
I'm an AAC-LC supporter for my personal stuff, but at work on linear we're using E-AC3 which I'm not proud of.

[modus-ms325c]

Off Topic on Doom9 but I am happy to see appreciation of AAC-LC. The Scene, people who are actually doing lots of encoding ( I want to say professional but I guess that is not the right word ) has made the right choice. It is just unfortunate most people dont get this and as AAC-LC is now fully patent free.
let me help

there are various reasons AAC-LC has fully gone under the radar in recent years, but what i think is chief among them is because we've been fed if not outright gaslit into new audio coding technologies that (no exceptions) promise "higher quality at lower bitrates" but when comes time to deliver, we just get diminishing returns instead

spectograms aren't the be-all-end-all of how sound actually sounds like when put to a lossy audio codec but insane frequency cutoffs are EVERYWHERE now and not a single soul cares about letting sound "breathe" anymore, it's now all about "sounding good" rather than "letting sound speak for itself", it's why you seem to like AAC-LC even more it seems!

[kurkosdr]

H.266 VVC has entered the evaluation phase for ATSC 3.0, which means that ATSC members will have to vote on that. It is difficult to predict exactly when the membership might vote to make it part of the standard, but the candidate standard period is typically less than a year, so just a few months. Given that DVB has already accepted it, chances are that it might get approved by the end of the year. :)
Sure, but what happens to all those existing UHD TVs sold the past 8 years that only decode HEVC UHD content?

Don't get me wrong, I want to see HEVC go away for 4K UHD broadcasts and be replaced by VVC, but unfortunately, I don't see it happening. For example, VVC is already part of the DVB toolset but it's used nowhere (there was a short trial of VVC-encoded 8K UHD by SES and that was it).

[kurkosdr]

They mentioned USAC, so I guess xHE-AAC, Netflix style, instead of a standard AAC-LC?
I don't know, though, just a wild guess, but for what it's worth I'm also a supporter of the good old AAC-LC.
I can see the utility of xHE-AAC for stuff like digital shortwave radio where most of the content is audio so there are savings to be had, but for video streaming? How much bitrate are you saving anyway to make it worth both the royalties cost and the compatibility breakage? Even video broadcasters don't use xHE-AAC, they use AAC-LC or HE-AAC (which I understand for channels with multiple audio tracks (languages), HE-AAC is backwards compatible with AAC-LC and offers some nice bitrate savings on multi-audio channels).

They mentioned USAC, so I

Side note:
I'm an AAC-LC supporter for my personal stuff, but at work on linear we're using E-AC3 which I'm not proud of.
I never understood why some countries (including France) use E-AC3 for stereo content instead of AAC-LC. The whole point of AC3 and E-AC3 is that 5.1 audio content encoded in these formats is compatible with every AVR/home cinema system ever made (note: E-AC3 receivers can transcode E-AC3 to AC3), but for stereo content? Use AAC-LC and it will exit the SPDIF hole as stereo LPCM. Broadcasters work in mysterious ways.

The only good thing about stereo E-AC3 is that it usually acts as a compatibility stream next to AC4, so it's a small annoyance that relieves us from a much bigger annoyance (AC4). But why won't they use AAC-LC for the stereo compatibility stream next to AC4? Guess I'll never know. I would guess Blu-Ray compatibility (since E-AC3 is transcodable to AC3), but they also use E-AC3 on HLG10 channels which aren't Blu-Ray-compatible as a matter of fact. As I said, broadcasters work in mysterious ways.

[kurkosdr]

The scene has started experimenting with VVC. Won't post a link but you can easily Google it up: Oppenheimer (2023) IMAX 2160p UHD HDR BluRay VVenC H.266 VVC AAC 5.1 [RAV1NE]
Do we know what AAC encoder they used?

They appear to be using "qaac" (which I guess is this one (https://github.com/nu774/qaac) but not sure) with "TVBR". What is TVBR?

[lvqcl]

True VBR
See https://github.com/nu774/qaac/wiki/Command-Line-Options

[FranceBB]

I never understood why some countries (including France) use E-AC3 for stereo content instead of AAC-LC. The whole point of AC3 and E-AC3 is that 5.1 audio content encoded in these formats is compatible with every AVR/home cinema system ever made (note: E-AC3 receivers can transcode E-AC3 to AC3), but for stereo content?

I don't know, but my wild guess is to keep things consistent and stick a -24 dialnorm value in there (i.e DRC). I don't know for sure, though, as my job ends once I've delivered the TX Ready file (i.e the one the video server plays before it gets re-encoded for distribution), then it's all in the end of the distribution guys. Funnily enough when I pass them a DolbyE 5.1 I also include a dialnorm value of -24 but when it comes to stereo it's always PCM anyway...



I can see the utility of xHE-AAC for stuff like digital shortwave radio where most of the content is audio so there are savings to be had


Well, we're currently stuck with HE-AAC 64 kbits which is honestly fine for dialogues but absolutely appalling for music. Then again, the fact that we're generally listening to music in the car with a lot of background noise makes the whole thing more forgiving but when I listen to the radio at home on my headsets the artifacts are pretty bad. And sure one could listen to the radio via internet, but the problem is that most companies (like global which handles a huge variety of radio stations) reuse the DAB+ HE-AAC live encode for the web, so...

These are just two examples:

Stream 1 HE-AAC 64 kbits Capital (Music) (http://media-the.musicradio.com/Capital?type=.flv)
Stream 2 HE-AAC 64 kbits LBC (Dialogues) (http://media-the.musicradio.com/LBCLondon?type=.flv)


Sure, but what happens to all those existing UHD TVs sold the past 8 years that only decode HEVC UHD content?


Nothing 'cause my mind was more oriented towards 8K.
I mean, DTT is a very different world, but currently on satellite we have SD channels still in MPEG-2, FULL HD channels still in H.264 and UHD channels in H.265. It's just natural to think that 8K channels will likely be H.266.

[Selur]

What is TVBR?
'AAC True VBR mode' https://github.com/nu774/qaac/wiki/Command-Line-Options
https://wiki.hydrogenaud.io/index.php?title=Apple_AAC#afconvert
There have been some discussions over at HydrogenAudio about whether vbr or tvbr are better.

[kurkosdr]

Well, we're currently stuck with HE-AAC 64 kbits which is honestly fine for dialogues but absolutely appalling for music. Then again, the fact that we're generally listening to music in the car with a lot of background noise makes the whole thing more forgiving but when I listen to the radio at home on my headsets the artifacts are pretty bad. And sure one could listen to the radio via internet, but the problem is that most companies (like global which handles a huge variety of radio stations) reuse the DAB+ HE-AAC live encode for the web, so...

These are just two examples:

Stream 1 HE-AAC 64 kbits Capital (Music) (http://media-the.musicradio.com/Capital?type=.flv)
Stream 2 HE-AAC 64 kbits LBC (Dialogues) (http://media-the.musicradio.com/LBCLondon?type=.flv)
Yes, in radio broadcasting xHE-AAC might make sense because most of your content is audio. But in video broadcasting, even if we assume xHE-AAC saves you 30kbps per audio stream (a generous estimate), and even if you have 3 languages (audio streams), is a ~0.1Mbps worth of bitrate savings worth the massive compatibility breakage? No, and that's why no video broadcaster uses it (and I hope they don't in the future, but you never know with broadcasters).

But even when it comes to radio broadcasting, it makes you wonder why HE-AAC is suddenly not enough and how many radio channels are too many. There is a compatibility cost to moving to newer formats (for example all those existing DAB+ receivers becoming useless). Digital shortwave radio doesn't have this problem because it's a completely new thing.

[benwaggoner]

Yes, in radio broadcasting xHE-AAC might make sense because most of your content is audio. But in video broadcasting, even if we assume xHE-AAC saves you 30kbps per audio stream (a generous estimate), and even if you have 3 languages (audio streams), is a ~0.1Mbps worth of bitrate savings worth the massive compatibility breakage? No, and that's why no video broadcaster uses it (and I hope they don't in the future, but you never know with broadcasters).
100 Kbps can matter if targeting mobile devices, and xHE-AAC decode is effectively universal on mobile: Android, iOS, and Fire OS have all supported xHE-AAC decode for a couple of replacement cycles now.

And with new codecs like VVC, we can push video bitrates down enough that audio becomes an increasingly large part of the total payload.

[benwaggoner]

'AAC True VBR mode' https://github.com/nu774/qaac/wiki/Command-Line-Options
https://wiki.hydrogenaud.io/index.php?title=Apple_AAC#afconvert
There have been some discussions over at HydrogenAudio about whether vbr or tvbr are better.
Ah. So "vbr" there is a CVBR (Constrained VBR) ala setting --crf with a --vbv-maxrate and --vbv-bufsize. That's going to be preferable for streaming and combined video/audio delivery, as peak bitrates worst case can be defined. We need that for video as profile/level define a maximum bitrate for compatibility which we want to stay under.

TVBR would be an uncapped VBR, ala just using --crf or --qp without any profile/level VBV limitations. Potentially slightly better sound quality, and preferable for file-based playback.

Since there's only so high a bitrate can go with a codec, in practice there's not likely to be that much a difference unless the constrained bitrate is quite constrained.

[kurkosdr]

100 Kbps can matter if targeting mobile devices, and xHE-AAC decode is effectively universal on mobile: Android, iOS, and Fire OS have all supported xHE-AAC decode for a couple of replacement cycles now.

And with new codecs like VVC, we can push video bitrates down enough that audio becomes an increasingly large part of the total payload.
As long as xHE-AAC stays away from video broadcast (DVB and ATSC), I am happy. Streamers can always encode an HE-AAC fallback for older devices and serve accordingly (I don't like the idea of throwing away good smartphones in the name of "replacement cycles"/planned obsolescence, I still use my Nexus 5 and 5X as secondary phones). Although on streaming you won't save 100kbps but 30kbps (in our example above) because you are not streaming all 3 languages (audio streams) simultaneously like you do on broadcast. So, I highly doubt the usefulness of it, but as long as they provide a fallback (as they do usually), it's not an issue.

[MoSal]

As long as xHE-AAC stays away from video broadcast (DVB and ATSC), I am happy. Streamers can always encode an HE-AAC fallback for older devices and serve accordingly (I don't like the idea of throwing away good smartphones in the name of "replacement cycles"/planned obsolescence, I still use my Nexus 5 and 5X as secondary phones). Although on streaming you won't save 100kbps but 30kbps (in our example above) because you are not streaming all 3 languages (audio streams) simultaneously like you do on broadcast. So, I highly doubt the usefulness of it, but as long as they provide a fallback (as they do usually), it's not an issue.

This whole discussion was weird, since it managed to ignore the two facts that:

1- Opus exists.
2- Audio codecs don't need hardware (accelerated) support. Platform-level support is not an absolute requirement either. Apps can add software decoding for any audio codec without a noticeable downside like too much battery drainage (assuming no unusual complexity requirements).

There is a reason why xHE-AAC is not that exciting.

---

There is a third fact that HE-AAC is shit for anyone who has any respect for their ears. But let's not get into that.

[benwaggoner]

As long as xHE-AAC stays away from video broadcast (DVB and ATSC), I am happy. Streamers can always encode an HE-AAC fallback for older devices and serve accordingly (I don't like the idea of throwing away good smartphones in the name of "replacement cycles"/planned obsolescence, I still use my Nexus 5 and 5X as secondary phones).[QUOTE]
xHE-AAC is supported on really old phones. As long as it can upgrade to Android 9 or iOS 13, the decoder is there. That's all the way back to the iPhone 6s for Apple. Android updates are up to the whim of the OEM, of course, but five years is enough to get a pretty complete ecosystem refresh for mobile. Certainly most streaming apps don't support OS versions earlier than those.

But yeah, for broadcast broadcast, introducing new codecs is fraught and generally part of a massive shift. ATSC 1.0 to 3.0, for example (which still exists more in theory than practice). DVB seems to be able to get an update in more than once every few decades ;).

[QUOTE]Although on streaming you won't save 100kbps but 30kbps (in our example above) because you are not streaming all 3 languages (audio streams) simultaneously like you do on broadcast. So, I highly doubt the usefulness of it, but as long as they provide a fallback (as they do usually), it's not an issue.
There are several big benefits of xHE-AAC for streaming

Seamless switching between all bitrates. That wasn't supported between LC and HEv1 or HEv1 and HEv2.
Single codec scalable from perceptually lossless music down to very low bitrate speech
Better speech quality in general at lower bitrates
Better compression efficiency than any legacy AAC variant at any given bitrate or perceptual quality threshold.

[birdie]

MPC-HC 2.2.0 by clsid2 now supports VVC decoding natively, hooray!

https://github.com/clsid2/mpc-hc/releases

Probably uses native FFmpeg decoding which is far from being fully/properly optimized (vvdec is 2-3 times faster) but it's still freaking amazing.

[guest]

I'm not sure if I'm in the correct thread, but I'm trying to use this VCC Encoder:-

https://github.com/Disa-Kizonda/VVC-GUI-Encoder

And after setting up the "Ready to Use Pack", and loading a file, I get this error:-


'ffmpeg_vvceasy.exe' is not recognized as an internal or external command,
operable program or batch file.
Exception in Tkinter callback
Traceback (most recent call last):
File "C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.9_3.9.3568.0_x64__qbz5n2kfra8p0\lib\tkinter\__init__.py", line 1892, in __call__
return self.func(*args)
File "C:\Users\Geoff\Downloads\VVC_GUI_Encoder\VVC_GUI_Encoder.py", line 10, in SelectButton
imgone=Image.open('temp.jpg')
File "C:\Users\Geoff\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.9_qbz5n2kfra8p0\LocalCache\local-packages\Python39\site-packages\PIL\Image.py", line 3277, in open
fp = builtins.open(filename, "rb")
FileNotFoundError: [Errno 2] No such file or directory: 'C:\\Windows\\System32\\temp.jpg'


'C:\\Windows\\System32\\temp.jpg' this doesn't look right, either...

double \\ ???

[LigH]

Regarding the double backslash: I am almost sure this is not the problem, just a required convention on Windows; but expecting a temporary JPEG file in Windows\system32 is an issue: No application should try to create files there. I guess the converter searches there for a file it did not find elsewhere, maybe because a verbose path to that file is missing. Searching alternatively in the system directory of Windows may be fine when looking for required DLLs, but not when looking for general data files.

Also note:
'ffmpeg_vvceasy.exe' is not recognized as an internal or external command, operable program or batch file.
Your package might be incomplete. Or it is not set up correctly with verbose paths to find the used tools.

[LigH]

Looking for "VVC encoder GUIs", I also found this project which might be interesting for some Linux users:

aviator - https://github.com/gianni-rosato/aVVCator
A Flatpak-first easy-to-use GUI for encoding with VVenC & aac.

[guest]

Looking for "VVC encoder GUIs", I also found this project which might be interesting for some Linux users:

aviator - https://github.com/gianni-rosato/aVVCator
A Flatpak-first easy-to-use GUI for encoding with VVenC & aac.

I need something pretty easy to use, don't like CLI stuff.

This one looks interesting:-

https://github.com/MartinEesmaa/VVCEasy

[birdie]

Please exercise extra caution when using random github projects or anything you download from the Internet.

In a perfect world you either run such things under a separate limited user account (given your system is 100% up to date/still supported/fully updated), or better yet in a virtual machine (virtualbox, vmware, qemu/kvm, etc), again under a limited user account.

The same applies to various PPA/COPR/AURs/whatever.

[guest]

Please exercise extra caution when using random github projects or anything you download from the Internet.

In a perfect world you either run such things under a separate limited user account (given your system is 100% up to date/still supported/fully updated), or better yet in a virtual machine (virtualbox, vmware, qemu/kvm, etc), again under a limited user account.

The same applies to various PPA/COPR/AURs/whatever.

Most of that didn't make any sense to me at all...

What do you suggest I use, that is an easy to use GUI ??

[birdie]

And now FFmpeg 7.0 as well!

"A new major release (https://ffmpeg.org/download.html#release_7.0), FFmpeg 7.0 "Dijkstra", is now available for download. The most noteworthy changes for most users are a native VVC decoder (currently experimental, until more fuzzing is done)"

MPC-HC 2.2.0 by clsid2 now supports VVC decoding natively, hooray!

https://github.com/clsid2/mpc-hc/releases

Probably uses native FFmpeg decoding which is far from being fully/properly optimized (vvdec is 2-3 times faster) but it's still freaking amazing.

[birdie]

It's weird, Qualcomm boasts about Adreno (https://www.qualcomm.com/developer/blog/2024/04/offload-tough-workloads-to-adreno-gpus--acceleration-of-the-adap) being able to decode 4K 60fps VVC video in real time in software mode on Snapdragon 8 Gen 2.

Meanwhile aside from MX Player no one seems to be interested.

[oibaf]

It's weird, Qualcomm boasts about Adreno (https://www.qualcomm.com/developer/blog/2024/04/offload-tough-workloads-to-adreno-gpus--acceleration-of-the-adap) being able to decode 4K 60fps VVC video in real time in software mode on Snapdragon 8 Gen 2.

Meanwhile aside from MX Player no one seems to be interested.

https://blog.chiariglione.org/a-future-without-mpeg/

[kurkosdr]

It's weird, Qualcomm boasts about Adreno (https://www.qualcomm.com/developer/blog/2024/04/offload-tough-workloads-to-adreno-gpus--acceleration-of-the-adap) being able to decode 4K 60fps VVC video in real time in software mode on Snapdragon 8 Gen 2.

Meanwhile aside from MX Player no one seems to be interested.
It's rather simple: Every chip or software player I've seen so far that can decode VVC can also decode AV1, but the reverse isn't always true. There are chips and software players out there that can decode AV1 but not VVC. Whatever marginal better performance VVC has over AV1, it's not worth breaking compatibility with those chips and software players. I'd even say it's not worth paying the royalties to implement a VVC decoder in smartphones, tablets, PCs, and software players. No streaming content in VVC means no reason to pay to implement a decoder.

[kurkosdr]

https://blog.chiariglione.org/a-future-without-mpeg/
So what? MPEG has no god-given right to exist, and neither do the for-profit companies that contribute the technologies (patents) behind it. As I've said elsewhere, now that MPEG doesn't have an automatic compatibility advantage (like HEVC has over VP9) and now that AV1 can do HDR10+, the companies behind MPEG have to earn their royalty dollars by competing with AV1 in the streaming space, for example by offering a performance delta over AV1 to be worth the royalty costs (including decoder royalties, encoder royalties, and content royalties). Simply put, no smartphone SoC vendor or software player vendor is obligated to support VVC. My guess is that VVC will eventually get some success in broadcasting (and as a result be supported in TVs alongside AV1), because broadcasters are obligated to use ISO or ETSI standards, but not elsewhere. Whether this is enough to keep the companies behind MPEG interested in developing new standards remains to be seen.

[ksec]

It's weird, Qualcomm boasts about Adreno (https://www.qualcomm.com/developer/blog/2024/04/offload-tough-workloads-to-adreno-gpus--acceleration-of-the-adap) being able to decode 4K 60fps VVC video in real time in software mode on Snapdragon 8 Gen 2.

Meanwhile aside from MX Player no one seems to be interested.

Because MX Player ( And Tencent ) are the only ones streaming VVC at the moment.

[benwaggoner]

https://blog.chiariglione.org/a-future-without-mpeg/
There was a good amount of talk about VVC at NAB a couple of weeks ago. More traditional video companies like broadcasters and cable are pretty much assuming that's what they'll be using down the road.

One talking point was that VVCEnc is already delivering equivalent quality to x265 at 70% the bitrate, which is an impressive delta at this point in the adoption curve given the relative maturity of the encoders.

Still, there's too much murk around the IP licensing for lots of markets. Things got somewhat simplified with Dolby integrating two of the three major patent pools, and Dolby is good at getting paid for licensed technology.

There was talk about AV2, but at least as much about how it keeps getting delayed due to not meeting its compression efficiency goals relative to VVC. I have no doubt it'll be a good codec, and a big improvement on AV2. Until we get close to a bitstream lockdown, it's a lot of speculation about where it'll land. Hopefully we'll get some useful demos for NAB 2025.

[Dann0245]

VVC film grain

https://arxiv.org/pdf/2402.00622

[LigH]

New uploads: [Windows][GCC 14.1.0][64 bit]

VTM Encoder/Decoder Version 22.0 (https://www.mediafire.com/file/w5zlpc94g0m07sb/VTM_22.0_463b869.7z/file) 463b869

Fraunhofer VVC Encoder ver. 1.11.1 (https://www.mediafire.com/file/m5pqaik0ibwokm6/vvenc_1.11.1-e4bb886.7z/file) e4bb886

Fraunhofer VVC Decoder ver. 2.3.0 (https://www.mediafire.com/file/fwvja2kb8nvs14z/vvdec_2.3.0-b3514f7.7z/file) b3514f7

[LigH]

PS: MP4Box can create an MP4 containing VVC video. But VLC with plugin does not decode the video in it.

That day (June 9, 2022) I created VLC issue 27055 (https://code.videolan.org/videolan/vlc/-/issues/27055); today a developer got assigned.

PS: Reading the history of comments in it again makes me sigh deeply.

[kurkosdr]

That day (June 9, 2022) I created VLC issue 27055 (https://code.videolan.org/videolan/vlc/-/issues/27055); today a developer got assigned.

PS: Reading the history of comments in it again makes me sigh deeply.
Generally, when it comes to VLC, you should assume a given bug is going to be fixed whenever or never. Those people have no process to rank bugs according to importance or popularity, so VLC is basically a hobby project with a professional-looking website. Hence the "send patches" response.

A characteristic example of this is how they still haven't implemented DVD-Video forced subtitles decades after DVD-Video support was added to VLC, which makes any DVDs that use forced subs to subtitle a foreign language/elvish/alienspeak unwatchable. The bug for this issue (#1135) is still open 17 years later.

I just moved to Kodi for my DVD-watching needs, and I suggest you do something similar: Find a player that can play VVC today or risk waiting for decades for VLC to add it.

[birdie]

VVdec has added support for the "film grain synthesis" attribute: https://github.com/fraunhoferhhi/vvdec/pull/178

Add film grain synthesis (based on VFGS). When an FGC SEI message is found in the bitstream, it is decoded and used to synthesize grain on top of the regular decoded picture. No specific commandline options are added, everything is automatic and hardwired = currently there is no way to disable FG synthesis if an FGC SEI message is received.

[birdie]

Just announced Intel Lunar Lake / Xe2-LPG (https://www.anandtech.com/show/21425/intel-lunar-lake-architecture-deep-dive-lion-cove-xe2-and-npu4/6) has been confirmed to support hardware VVC decoding. Finally.

[FranceBB]

I really hope an option is introduced to prevent reintroducing the already removed grain. It would make everyone happy: those who like grain can leave it on and those who prefer cleaner pictures like me just need to disable it, while both of us get the compression efficiency by coding a smoother picture.

As for hardware decoding, that's very good to know from Intel. Feels like we're slowly getting to the point in which H.266 is actually getting usable. :)

[Jamaika]

"Also disclosed was the Intel NPU 4, which Intel claims delivers up to 48 TOPS, surpassing Microsoft's Copilot+ requirements for the new age of AI PCs."
What does new age of AI PCs mean?

"The main change affecting this is the addition of an additional 8 MB side cache, which allows for reduced traffic in the system memory for multimedia-based tasks."
Is this extra memory on the motherboard?

"Intel Lunar Lake has been even further rebuilt in terms of the Media Engine and Display Engine, which is probably the most extensive system in this matter among laptops.
In addition, there is support for HDMI 2.1 and DisplayPort 2.1 (we are talking about full support, i.e. UHBR10, UHBR13.5 and UHBR20, but the type of DP 2.1 supported in a given laptop will depend on the specific OEM) and eDisplayPort 1.5."
Are these power-saving processors just for laptop?

[FranceBB]

What does new age of AI PCs mean?


That's just a term made up by Microsoft to justify shipping Copilot in as many things they could.
Essentially, the era of "AI PC" started with ARM in which you had the normal parts of the CPU doing normal computations and then dedicated accelerators (you can think about them as part of the CPU) to perform AI-related tasks. This, in Microsoft's view, would offload some of the calculations from their datacenter GPUs to the dedicated co-processor unit inside the CPU in the consumer device for the most basic stuff. They set a target and both AMD and Intel did something to reach that so that they could be part of this "AI PC" or "Copilot+" marketing nonsense.

[MoSal]

What does new age of AI PCs mean?


PCs that do mostly-useless low-precision bad math fast in the name of intelligence.


" In addition, there is support for HDMI 2.1 and DisplayPort 2.1 (we are talking about full support, i.e. UHBR10, UHBR13.5 and UHBR20, but the type of DP 2.1 supported in a given laptop will depend on the specific OEM) and eDisplayPort 1.5."

It's not full support if Intel can't partner with others to pressure the HDMI forum to allow support for 2.1 on Linux, and threaten a future boycott if they don't budge (AMD tried alone and failed). Otherwise, "full support" and "no support" are equivalent for us, an admittedly small but significant percentage of users. Directing the cost incurred towards something else would actually be more beneficiary to us. This also applies to dedicated GPUs, which Intel also sells nowadays.

[Jamaika]

Thanks for your replies.
It will be more profitable to buy AMD or Intel. What amounts are we talking about?
As I understand it, AVX512 will replace AVX10. What economical power supply is needed for this? I understand that we will not buy 800W. How to configure it yourself?

[kurkosdr]

It's not full support if Intel can't partner with others to pressure the HDMI forum to allow support for 2.1 on Linux, and threaten a future boycott if they don't budge (AMD tried alone and failed).
HDMI is a front for Hollywood studios to make arbitrary demands to the consumer electronics industry (enabled by the DMCA's "anti-circumvention provisions"). If you don't obey, no HD or 4K HDR Hollywood content for you.

So, with that in mind, it's a case of the HDMI Forum boycotting anyone who doesn't comply with their demands, not the other way around.

[MoSal]

HDMI is a front for Hollywood studios to make arbitrary demands to the consumer electronics industry (enabled by the DMCA's "anti-circumvention provisions"). If you don't obey, no HD or 4K HDR Hollywood content for you.

So, with that in mind, it's a case of the HDMI Forum boycotting anyone who doesn't comply with their demands, not the other way around.

Boycotts/Threats is how we got a single high-capacity compact disc standard (DVD):
https://web.archive.org/web/19981202113012/http://product.info.apple.com/pr/press.releases/1995/q3/950503.pr.rel.cd.html

And if boycotts/threats don't work, hardware vendors/manufacturers could rally around and push for an alternative new standard if they wanted to. We have historical examples of same-gen but later-appearing standard B ending up killing standard A due to vendors not wanting to deal with A.

Hardware vendors/manufactures simply don't consider the current situation a deal breaker for them to want to take such steps.

[birdie]

I've found a treasure trove of sample VVC clips for testing:

https://dvb.org/specifications/verification-validation/vvc-test-content/

They need some name and email, you can type anything.

[benwaggoner]

I really hope an option is introduced to prevent reintroducing the already removed grain. It would make everyone happy: those who like grain can leave it on and those who prefer cleaner pictures like me just need to disable it, while both of us get the compression efficiency by coding a smoother picture.
I've looked at some degrained-for-FGS content with FGS turned off, and it can look pretty weird and unpleasant. The signal-noise ratio is quite low for a lot of grainy content, particularly 16mm and Super35. The degrained versions can kind of look soft and textureless, like a mediocre upscale.

The results aren't as good as a real high-quality noise reduction that mutes the excess grain, but leaves enough texture to keep things from looking abnormally flat.

As for hardware decoding, that's very good to know from Intel. Feels like we're slowly getting to the point in which H.266 is actually getting usable. :)
Wonderful news indeed!

[Yups]

Hardware decoding in action:

https://youtu.be/-2yxPal4wQI?t=1951

[kurkosdr]

Boycotts/Threats is how we got a single high-capacity compact disc standard (DVD):
https://web.archive.org/web/19981202113012/http://product.info.apple.com/pr/press.releases/1995/q3/950503.pr.rel.cd.html

And if boycotts/threats don't work, hardware vendors/manufacturers could rally around and push for an alternative new standard if they wanted to. We have historical examples of same-gen but later-appearing standard B ending up killing standard A due to vendors not wanting to deal with A.

Hardware vendors/manufactures simply don't consider the current situation a deal breaker for them to want to take such steps.
You mean like how Hollywood studios picked the winner of the HD-DVD vs Blu-Ray format war by deciding one day to only throw content at one format (Blu-Ray) while letting the other rot (HD-DVD)? This happened shortly after BD+ gave studios the hope of unbreakable DRM. Whatever studio support HD-DVD had dried up right there and then.

Or how Hollywood studios cut out MacOS X from Blu-Ray and HD-DVD support because MacOS X didn't provide the DRM infrastructure Hollywood studios demanded for Blu-Ray and HD-DVD?

It doesn't matter what happened in the distant past, today pre-recorded content is king and DRM is legally empowered by the DMCA. Hollywood studios can cut out from their encrypted content whatever OS and hardware combination doesn't comply with their arbitrary demands. I mean, what can AMD and Intel do? "Boycott" HDMI 2.1 and come out and say "Nvidia GPUs as well as every $400 console out there support HDMI 2.1 but our flagship GPUs don't, please buy our flagship GPUs"? If they do that, they might get that 2% of users running Desktop Linux but will lose the much bigger market of Windows users who want their new GPU to support HDMI 2.1.

The weird thing in this case is that HDMI 2.1 is required only if you want 4K@120fps, and Hollywood doesn't serve any 4K@120fps content, but they can still mandate all kinds of DRM requirements by acting as gatekeepers to the HDMI spec. DisplayPort is technically a thing but isn't a thing on TVs (due to lack of eARC support), so you want at least one HDMI 2.1 port if you want to output 4K@120fps to a TV (which means GPU vendors can't boycott HDMI 2.1). And then there is the open question of whether encrypted 8K content will be allowed on DisplayPort or be HDMI 2.1-only.

[ksec]

Hardware decoding in action:

https://youtu.be/-2yxPal4wQI?t=1951

Great, excluding CPU and GPU that is probably around 2W decoding 4K. Good for Desktop, Good Enough for Laptop. not quite Smartphone ready yet. But hopefully next year for Qualcomm Mediatek and Apple.

Now we need encoders.

[FranceBB]

Hold on a second, I thought that the whole thing about HDMI 2.1 not being allowed on Linux was only because AMD tried to make the support part of its open source driver.
I might be wrong here, but I remember reading people suggesting AMD to ship a binary blob instead so that it would have been accepted.
Did I get it wrong?

[Yups]

Great, excluding CPU and GPU that is probably around 2W decoding 4K. Good for Desktop, Good Enough for Laptop. not quite Smartphone ready yet. But hopefully next year for Qualcomm Mediatek and Apple.

Now we need encoders.


Maybe less because the RAM is included in the package power on Lunar Lake. Encoding hopefully on Xe3.

[ksec]

Maybe less because the RAM is included in the package power on Lunar Lake. Encoding hopefully on Xe3.

I would expect at least 1W during active use. That puts decoding into 1W category. Sub 1W when deciding 1080P / 2K content. Pretty impressive. That doesn't take into account the bitrate it was decoding. Sounds like good enough for me!

Bring me x266!

[oibaf]

Dolby Laboratories to acquire GE Licensing in $429m deal (https://finance.yahoo.com/news/dolby-laboratories-acquire-ge-licensing-101608757.html)

Technology company Dolby Laboratories has announced a definitive agreement to acquire GE Licensing from GE Aerospace in an all-cash deal valued at $429m.The inclusion of GE Licencing’s video codec technology patents such as HEVC and VVC will complement and expand Dolby's existing intellectual property portfolio.