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

[quietvoid]

Okay, so it's back to having to specify the whole GOP structure. I can reproduce the same error when removing all the Frame lines.
In config files, it refers to this: https://vcgit.hhi.fraunhofer.de/jvet...vtm.cfg#L20-51

I don't know if they can be specified by command line

[Jamaika]

Originally Posted by FranceBB

Output:

Error: found fewer Reference Picture Sets than GOPSize
Error: Invalid GOP structure given

You aren't using correct codec. This one is experimental and for setting only GOP = 16 or 32 in config.
You should use the vvenc and vvdec with multithread versions.

Originally Posted by FranceBB

however I specified the correct GOP with a size of 4 and I set the --IntraPeriod to -1 which means automatic, so it should be ok.
I also took care of the CTU size and made sure that all the Slices were the same (so at least equal or less than it) and I set --Log2MaxTbSize to be less than 6, as suggested.
Still, it's complaining again. Why?
Besides, I think it should really allow default settings to go through rather than throwing errors all the time.
I mean, if someone doesn't specify anything, it throws an error 'cause it wants things to be specified.
If someone specifies them wrong, it doesn't clearly work, however there's very little documentation (at least, that's what I've found).
It's a bit of a pain to work with it, honestly....

These were the settings for screenshot at GOP = 1. Then you can skip config.

[FranceBB]

Originally Posted by Jamaika

You aren't using correct codec. This one is experimental and for setting only GOP = 16 or 32 in config.
You should use the vvenc and vvdec with multithread versions.

These were the settings for screenshot at GOP = 1. Then you can skip config.

Where can I find the stable multithreaded one, then?

[Jamaika]

https://github.com/fraunhoferhhi/vvdec
https://github.com/fraunhoferhhi/vvenc
plus my fix
I have added codecs and compilation issues in my threads

[FranceBB]

Originally Posted by Jamaika

https://github.com/fraunhoferhhi/vvdec
https://github.com/fraunhoferhhi/vvenc
plus my fix
I have added codecs and compilation issues in my threads

Thanks!
Last question: from what I see it's still uncompressed .yuv input file only, so I assume a -f yuv4mpegpipe - | from FFMpeg wouldn't work, right?

[hajj_3]

Does anyone know whether an open source optimised VVC software decoder is being made by anyone?

[birdie]

Originally Posted by hajj_3

Does anyone know whether an open source optimised VVC software decoder is being made by anyone?

I'm quite sure many companies are already developing coders and decoders behind closed doors but in terms of open source support/solutions it's been dead quiet except for an encoder from Multicoreware which was announced several months ago.

Sharp meanwhile has announced a real time decoder for up to 8K VVC streams: https://global.sharp/corporate/news/201204-a.html I've tried to dig deeper but it looks like the corporation is averse to open source ;-)

[birdie]

Speaking of the reference encoder, vvcenc, it's already quite fast without tons of hand-written optimizations/assembly: https://www.streamingmedia.com/Artic...ow-144235.aspx

Looks like when it gets properly optimized it'll be a lot faster than aomenc (though now the reference AV1 encoder is SVT-AV1 which I haven't yet accepted as its quality is quite poor IMO).

[Marsu42]

Originally Posted by birdie

Looks like when it gets properly optimized it'll be a lot faster than aomenc

That shouldn't be a surprise, should it?

Afafik av1 ist a "simply try everything" encoder, because patented mpeg fast prediction tools aren't included.

So even if vvc has added complexity vs hevc vs avc, it should be still more tuned for fast encoding - while av1 is designed to avoid patents and tuned for either "quality doesn't matter" video calls or "cost doesn't matter' encoding by streaming providers.

[foxyshadis]

Originally Posted by Marsu42

That shouldn't be a surprise, should it?

Afafik av1 ist a "simply try everything" encoder, because patented mpeg fast prediction tools aren't included.

So even if vvc has added complexity vs hevc vs avc, it should be still more tuned for fast encoding - while av1 is designed to avoid patents and tuned for either "quality doesn't matter" video calls or "cost doesn't matter' encoding by streaming providers.

I think it's more that AV1 followed a similar trajectory as the messy H.264/AVC spec process, with lots of freewheeling tools and an unmaintainable, unoptimizable codebase. JM was a joke for many years, but with a surprising amount of work it got much better despite not having a market; eventually the HM (H.265/HEVC) used its base to graft new tools on instead of starting from scratch, and H.266/VVC is doing the same with an even more mature and optimized base. What that also means is that you aren't going to see the kinds of staggering differences between JM and an x264 anymore.

AV1 threw out lots of baby with the bathwater in trying for a total do-over of codec development, instead of just building off of VP9, because it ended up so different. (Not the VP9 was any peach.) Other AV1 implementations have tons of freedom to do much better, which is both better and unfortunate. A future AV2 will have the benefit of whatever portion of aom's code and optimizations are reusable. It's not like AV1 finalized pie in the sky proposals, though; just like every MPEG process, there was a painful period of cutting them down to what met a size and performance budget, and that's a huge part of why the final spec was so delayed.

But also, AV1 didn't benefit from the large number of experienced chip designers who weigh in on all MPEG proposals regarding baking it into transistor budgets. C'est la vie.

[hajj_3]

Originally Posted by foxyshadis

AV1 threw out lots of baby with the bathwater in trying for a total do-over of codec development, instead of just building off of VP9, because it ended up so different. (Not the VP9 was any peach.) Other AV1 implementations have tons of freedom to do much better, which is both better and unfortunate. A future AV2 will have the benefit of whatever portion of aom's code and optimizations are reusable.

Some of the nice things about a future AV2 codec are:

1. lots of patents will have expired.
2. sisvel published a list of patents they claim that av1 violates therefore av2 can be developed to make sure that those aren't violated.
3. unifiedpatents.com have been successfully invalidating some av1 and hevc patents which means that some of those patents will be able to be used.

I do hope that AV2 isn't ratified within 5yrs of AV1 though, otherwise it might make a difficult for AV1 to become popular.

[Jamaika]

Untested info
No video player can show this. Full compatibility can be expected in a year's time!

mp4box.exe -new -info -add import.vvc output.mp4

Codec VVC in conteiner mp4.

Track Importing HEVC - Width 1280 Height 720 FPS 25000/1000 SAR 0/0
VVC Import results: 55 samples (144 NALUs) - 55 SEI - 3 IDR
VVC Stream uses forward prediction - stream CTS offset: 55 frames
VVC Max NALU size is 63768 - stream could be optimized by setting nal_length=2
# Movie Info - 1 track - TimeScale 600
Duration 00:00:00.000 (recomputed 00:00:04.240)
Fragmented: no
Major Brand iso4 - version 1 - compatible brands: iso4
Created: GMT Wed Jan 6 21:02:22 2021


# Track 1 Info - ID 1 - TimeScale 25000
Media Duration 00:00:00.000 (recomputed 00:00:02.200)
Track has 1 edit lists: track duration is 00:00:04.240
Media Info: Language "Undetermined (und)" - Type "vide:vvc1" - 55 samples
Visual Sample Entry Info: width=1280 height=720 (depth=24 bits)
Visual Track layout: x=0 y=0 width=1280 height=720
VVC Video - Visual Size 1280 x 720
VVC Info: Profile 1 @ Level 64 - Chroma Format YUV 4:2:0

NAL Unit length bits: 32
Parameter Sets: 1 SPS 1 PPS
Bit Depth 8 - 5 temporal layers
SPS#1 hash: CD7EE785B89AF3327C233B50CA28C755D751EAFA
PPS#1 hash: FF54700DA8418365C4BB4330DEE1EF986AA37AAC

RFC6381 Codec Parameters: vvc1.1.L64
Average GOP length: 27 samples
Max sample duration: 0 / 25000

0.500 secs Interleaving

[FranceBB]

Sweet, so it's possible to mux in mp4 as well and not just mkv. Good.
Apart from the container, is there any player at all (beside the DecoderApp.exe) that can play VVC files?
And last but not least: any news from Multicoreware about x266?

[quietvoid]

There seems to be a x266 repo on MCW's Bitbucket since October or something, but it's still private.

[FranceBB]

Originally Posted by quietvoid

There seems to be a x266 repo on MCW's Bitbucket since October or something, but it's still private.

I see! So they're waiting to get things going before opening to open source. Well, it kinda makes sense, I think...

[birdie]

ffmpeg hasn't even begun adding support for VVC. That looks weird, the codec uptake seems to be extremely slow.

[Jamaika]

What is this talking about?
GPAC did what it could. I exerted pressure. There aren't resources for modifying new codecs in GPAC jpeg2000, avif, heif.
I remind you that in jpeg.org propaganda heif photos can contain and convert to HTJPEG2000. It is fantasy right now. There are no funds or there are paid programs somewhere.
https://jpeg.org/jpeg2000/index.html
JPEGXS will not come out free this year. It was supposed to be the successor to jpeg2000.
https://www.iis.fraunhofer.de/en/ff/...on/jpegxs.html
https://www.intopix.com/ffmpeg
Google codecs are for google and the rest don't count. The rest as competition will not support google.
The mpeg5 container had new features mainly anti-piracy in the network under vvc, evc codecs. The strange thing is we have mp4 and matroska from vvc. SONY is sure to be happy as he fought with matroska.
https://github.com/MPEGGroup/isobmff
The creators of m-ad-s laughed at me with the answer. Write better, create your own library, but they advertise google codec aom.
https://github.com/m-ab-s/media-auto...commits/master

[Jamaika]

x266 Open-Source Encoder for VVC by MulticoreWare
https://ottverse.com/x266-vvc-multic...ource-encoder/
If you have any questions for the MulticoreWare team, please get in touch with Shivakumar Narayanan at x266@multicorewareinc.com.

[Jamaika]

Untested

Main Features
Spliting video by scenes for parallel encoding because AV1 encoders are currently not good at multithreading, encoding is limited to single or couple of threads at the same time.

PySceneDetect used for spliting video by scenes and running multiple encoders.
Fastest way to encode AV1 without losing quality, as fast as many CPU cores you have :).
Target Quality mode. Targeting end result reference visual quality. VMAF used as substructure
Resuming encoding without loss of encoded progress.
Simple and clean console look.
Automatic detection of the number of workers the host can handle.
Building encoding queue with bigger files first, minimizing waiting for the last scene to encode.
Both video and audio transcoding with FFmpeg.
Logging of progress of all encoders.
Install
Prerequisites:

Install Python3
When installing under Windows, select the option add Python to PATH in the installer
Install FFmpeg
Recommended to install vapoursynth with lsmash for faster and better processing
Encoder of choice:

Install AOMENC
Install rav1e
Install SVT-AV1
Install SVT-VP9
Install vpx VP9, VP8 encoding
Install VTM VVC encoding test model
Optional :

Vapoursynth
ffms2
lsmash
mkvmerge

If someone compiles, let him praise it.
https://github.com/master-of-zen/Av1an

[FranceBB]

Originally Posted by Jamaika

x266 Open-Source Encoder for VVC by MulticoreWare
https://ottverse.com/x266-vvc-multic...ource-encoder/

Well, it really just says:

For the larger open source community, it will be made available when we have reached critical mass required for its first release. As we near readiness, we will update here on how you can get hold of it.

so, again, they're working on it, but we can't see it yet, so all we have is the encoder_app.exe reference encoder