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

[Jamaika]

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

[LigH]

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

[Jamaika]

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

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

[LigH]

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

The media-autobuild suite enabled compiling with split parallelism.

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

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

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

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

[foxyshadis]

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

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

[Jamaika]

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

[LigH]

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

[Wolfberry]

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

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

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

[Jamaika]

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

[LigH]

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

[Jamaika]

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

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

delete
#define HEVC_TILES_WPP 1
#define JVET_MMVD_OFF_MACRO 0

[Jamaika]

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

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

[EwoutH]

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

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

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

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

[Jamaika]

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

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


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

[EwoutH]

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

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

[Pushman]

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

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

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

[EwoutH]

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

Thanks, got it working!

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

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

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

[EwoutH]

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

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

[benwaggoner]

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

[EwoutH]

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

[soresu]

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

[iwod]

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

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

[iwod]

There is a new article from BBC R&D

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

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

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

[Jamaika]

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

[benwaggoner]

There is a new article from BBC R&D

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

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

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

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

[Jamaika]

- new fixes for codec VVC 5.0 2019.06.01

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

[Jamaika]

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

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

[IgorC]

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

[birdie]

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

I've converted it to PDF:

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

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

[iwod]

So around 35% to 40% reduction.

Are there any similar test done for EVG?

[MoSal]

Is the Sedof sequence available somewhere?

[Jamaika]

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

[Jamaika]

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

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

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

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

[Jamaika]

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

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

55:#include "mingw.mutex.h"

seems very platform specific.

[jonatans]

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

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

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

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

[Adonisds]

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

[hajj_3]

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

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

[Jamaika]

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

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

[iwod]

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

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

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

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

[benwaggoner]

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

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

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

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

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

[iwod]

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

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

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

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

Competition is great.

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

[Jamaika]

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

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

[benwaggoner]

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

Competition is great.

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

[benwaggoner]

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

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

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

[Jamaika]

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

[Jamaika]

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

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

[iwod]

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

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

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

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

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

[benwaggoner]

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

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

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

[benwaggoner]

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

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

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

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

[Jamaika]

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