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

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