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

[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.