Trying to compile VVC in MSYS2/MinGW64 using GCC 13.1 fails, the same error as in many other projects since GCC got updated from v12 to v13:

In file included from G:/MABS/build/vvc-git/source/Lib/CommonLib/CommonDef.h:65,
                 from G:/MABS/build/vvc-git/source/Lib/CommonLib/AdaptiveLoopFilter.h:41,
                 from G:/MABS/build/vvc-git/source/Lib/CommonLib/AdaptiveLoopFilter.cpp:38:
G:/MABS/build/vvc-git/source/Lib/CommonLib/TypeDef.h:253:15: error: 'int16_t' does not name a type
  253 | typedef       int16_t           Pel;               ///< pixel type
      |               ^~~~~~~
G:/MABS/build/vvc-git/source/Lib/CommonLib/TypeDef.h:54:1: note: 'int16_t' is defined in header '<cstdint>'; did you forget to '#include <cstdint>'?
   53 | #include "CommonDef.h"
  +++ |+#include <cstdint>
   54 | 
G:/MABS/build/vvc-git/source/Lib/CommonLib/TypeDef.h:255:15: error: 'int16_t' does not name a type
  255 | typedef       int16_t           TMatrixCoeff;      ///< transform matrix coefficient
      |               ^~~~~~~
G:/MABS/build/vvc-git/source/Lib/CommonLib/TypeDef.h:255:15: note: 'int16_t' is defined in header '<cstdint>'; did you forget to '#include <cstdint>'?
G:/MABS/build/vvc-git/source/Lib/CommonLib/TypeDef.h:256:15: error: 'int16_t' does not name a type
  256 | typedef       int16_t           TFilterCoeff;      ///< filter coefficient
      |               ^~~~~~~
G:/MABS/build/vvc-git/source/Lib/CommonLib/TypeDef.h:256:15: note: 'int16_t' is defined in header '<cstdint>'; did you forget to '#include <cstdint>'?
{...}

Probably at least the following files need an additional #include <cstdint>:

• source/Lib/CommonLib/CommonDef.h
• source/Lib/CommonLib/TypeDef.h
• source/Lib/CommonLib/dtrace.h
• source/Lib/CommonLib/Hash.h
• source/Lib/Utilities/program_options_lite.h

When we encode which is in y4m input, the frame rate and other input metadata are present in the header. This is also expected when we decode a bitstream to y4m.

Background

Currently in VVC, when we try to decode a video (bitstream) to Y4M format, it suggests there is no framerate info in the bitstream and fallback to the default 50fps. This is not the correct behaviour. If it is YUV, we don't care about the frame rate inside the decoded stream, it is not the case here.

Steps to reproduce

1. Encode a video which is in y4m

EncoderAppStatic -i FourPeople_480x270_60.y4m -c vvc-vtm/encoder_randomaccess_vtm.cfg --InputBitDepth=10 --FramesToBeEncoded=1 --QP=50 --ReconFile=Fourpeople-recon.yuv -b fourpeople.bin The sample used in this example: ​https://media.xiph.org/video/aomctc/test_set/a5_270p/FourPeople_480x270_60.y4m

2. Decode video to y4m format

./bin/DecoderAppStatic -b fourpeople.bin -o four.y4m

3. Inspect the input headers and output headers to cross-check

SRC: head -1 /media/aomctc-a5-270p/FourPeople_480x270_60.y4m SRC: YUV4MPEG2 W480 H270 F60:1 Ip A0:0 C420jpeg XYSCSS=420JPEG ENC_STREAM: head -1 four.y4m ENC_STREAM: YUV4MPEG2 W480 H270 F50:1 Ip A0:0 C420p10

Samples Any y4m samples would be sufficient,

Workarounds If we explicitly signal HRDParameters with SEIPictureTiming and BufferPeriod, we get the approximate frame-rate (no idea why not same for all the clips) in the decoded y4m file, --HrdParametersPresent=1 --SEIPictureTiming=1 --SEIBufferingPeriod=1 --RCCpbSize=1000

YUV4MPEG2 W480 H270 F60000:1001 Ip A0:0 C420p10 It suggests 59.94 instead of 60fps for this sample clip. So I do not know if this is the correct way to handle frame-rate information in VVC, I have little idea as a whole for VVC. At the same time, for some other clips which has fractional frame rates (only tested with 2-4 clips, so not yet conclusive) it gives the correct framerate in the output y4m. Another broken example, Input: ​https://media.xiph.org/video/aomctc/test_set/a2_2k/MountainBike_1920x1080_30fps_8bit.y4m Encode-settings: same as above SRC: YUV4MPEG2 W1920 H1080 F30:1 Ip A1:1 C420jpeg XYSCSS=420JPEG ENC_STREAM: YUV4MPEG2 W1920 H1080 F30000:1001 Ip A0:0 C420p10 Another working example, Input: ​https://media.xiph.org/video/aomctc/test_set/a5_270p/Vertical_Bayshore_270x480_2997.y4m SRC: YUV4MPEG2 W270 H480 F30000:1001 Ip A0:0 C420jpeg XYSCSS=420JPEG ENC_STREAM: YUV4MPEG2 W270 H480 F30000:1001 Ip A0:0 C420p10

Question I would assume it falls back to 420p10 due to the internal 10-bit pipeline in the configuration of VVC. Would be beneficial to have a clarification for that.

Best, V

Hi,

Background We have been trying to integrate VVC into a popular compression testing framework, AreWeCompressedYet (AWCY)[1]. Typically we store the input videos as Y4M files for ease of file handling and maintainability. We have the initial support of VVC_VTM in an experimental YUV pipeline, where the videos are converted from y4m->yuv on the fly. it is problematic when we want to scale the jobs. Thus y4m is useful as other encoders are built and tested with y4m for many years.

Y4M is a not-so-well-defined spec, [in fact no official spec per-se! (?)], so different authors/encoders have different implementations. Thus implementing is a bit tricky. One page which people tend to refer to as a loose spec is the multimedia wiki[2], which is obviously not fully defined, thus discrepancies are there.

VVC have initial support for encoding and decoding of Y4M files, which works well for most cases. I have been testing and comparing the YUV encoding pipeline with the Y4M encoding pipeline for various videos typically available in our xiph's Media collection[2] and other public resources. In the testing, there was this edge case where the VVC-VTM is not handling c420mpeg2 Y4M files correctly. Not handling in the sense, the bitstream in a YUV pipeline is mismatched from the same file in Y4M pipeline. At the same time if hack the chroma-format to be 420 or 420jpeg it works and gives bit-identical output

What is 420mpeg2?

I tried to have a bit of digging into this, and it seems to be there since ~2006 in the mjpegtools[3]. And other public implementations of y4m handlers[4,5,6,7, 8] CLI from yuv4mpeg 420mpeg2 - 4:2:0 MPEG-2 (horiz. cositing) Many samples on the internet are with 420mpeg2.

Proposed solution Typically in y4m readers, say HDRTools, FFmpeg or any other libraries which supports many y4m inputs, it is handles in the input parsing is the same as other 420 input formats[4,6,7,8]. So one quick fix would be handling it in the same fashion as 420jpeg in VVC-VTM[9] to mimic other public implementations.

Samples ​https://media.xiph.org/video/aomctc/test_set/b1_syn/EuroTruckSimulator2_1920x1080p60_v2.y4m ​https://media.xiph.org/video/aomctc/test_set/b1_syn/STARCRAFT_1080p60.y4m ​https://media.xiph.org/video/aomctc/test_set/a4_360p/BlueSky_360p25_v2.y4m

Sample command line EncoderAppStatic -i $INPUT.Y4M -c encoder_randomaccess_vtm.cfg --ReconFile=$INPUT-recon.yuv --QP=$X -b $INPUT-bitstream.bin EncoderAppStatic -i $INPUT.YUV -c encoder_randomaccess_vtm.cfg --ReconFile=$INPUT-recon.yuv --SourceWidth=$WIDTH --SourceHeight=$HEIGHT --FrameRate=$FPS --InputBitDepth=$DEPTH --QP=50 -b $INPUT-bitstream.bin

Steps to reproduce

0. Build latest VVC-VTM
1. Encode a video with Y4M
2. Convert the y4m to YUV
3. Encode the same video in YUV pipeline
4. Cross-check the md5 of the bitstream and a mismatch is observed.
5. Modify the Y4M header to be non 420mpeg2[A.1]
6. Repeat 1..4, and you will get a bit-identical bitstream as expected.

[1]: ​https://github.com/xiph/awcy [2]: ​https://wiki.multimedia.cx/index.php/YUV4MPEG2 [2]: ​https://media.xiph.org/ [3]: ​https://mjpeg.sourceforge.io/ [4]: ​https://gitlab.com/standards/HDRTools/-/blob/master/common/src/InputY4M.cpp#L209 [5]: ​https://github.com/xiph/daala/blob/master/tools/y4m_input.c#L180 [6]: ​https://github.com/image-rs/y4m/blob/58375d69120a33e2a21320e17449e84e4de9949d/src/lib.rs#L249 [7]: ​https://gitlab.com/AOMediaCodec/avm/-/blob/main/common/y4minput.c#L909 [8]: ​https://source.ffmpeg.org/?p=ffmpeg.git;a=blob;f=libavformat/yuv4mpegenc.c;h=2fa5ee2714ddba9f15c998a9295f153b26a21985;hb=HEAD#l104 [9]: ​https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/-/blob/master/source/Lib/Utilities/VideoIOYuv.cpp#L233

[A.1]: Steps to modify a header echo "YUV4MPEG2 W640 H360 F25:1 Ip C420jpeg" > BlueSky_360p25_v3.y4m tail -n+2 BlueSky_360p25_v2.y4m >> BlueSky_360p25_v3.y4m

Please do let me know if you have any questions, Best, V