VVC support request

[ioctl-user]

Please consider adding optional VVC support using vvenc standalone app or library.

This standard codec is successor of the H.265, it outperforms AV1.

For now there not so many SW players, and no HW players, but it's only a matter of time before they appear.

The ones encoding video for long time archival storage may choose VVC over AV1 right now.

[trixoniisama]

VVC support used to be a thing around 2020 and it was removed once av1an switched from being python-based to rust-based.

There is no point in getting all hyped up for VVC, the codec is dead on arrival. Its patent's situation is worse than even HEVC was and as we can see 4 years after the format has been finalized, very early support is barely beginning in FFMPEG (and that's more because of an obligation to do so than anything else), but worse than that, adoption is near inexistent as well. Except for a few enthusiasts, nobody seems to care in the slightest for VVC and for good reasons: it's not the impressive jump over HEVC we were expecting it to be. Worse, it doesn't actually outperform AV1: it's barely trading blows with the best AV1 has to offer, while doing it at much slower speeds. VVC encoded videos are also extremely inconsistent and the lack of a film grain implementation (yet) is problematic for overall appeal, something AV1 excels at. VVenC also cannot compete with x265 in detail retention, so it's in a weird spot where it doesn't do anything much better than more convenient alternatives.

Therefore, someone would need to be a fool to "choose VVC over AV1 for long time archival storage" in the current state of things.

[trixoniisama]

Just wanted to add something before it gets all confusing, this is not me saying VVC encoders shouldn't be added to av1an, just me rambling about your VVC performance claims.

[ioctl-user]

My considerations are the following:

1. VVC decoding was added to the ffmpeg repo, so anyone will have possibility to play this format.
2. Patent situation is not valuable for video self storage.
3. Some people doesn't need features like film grain.
4. SVT-AV1 gives better VMAF Y NEG and SSIM YUV 6:1:1 quality, but significantly slower than VVEnc.
5. VVenc is faster and the same time gives better subjective quality than SVT-AV1 according to this extensive comparison.

If you have links to another solid research, please share them.

[master-of-zen]

I will look into this.
After I verify that I can encode/decode/mux and playback VVC with no issues. Last time I looked into this I couldn't remux and playback VVC.

[trixoniisama]

My considerations are the following:

1. VVC decoding was added to the ffmpeg repo, so anyone will have possibility to play this format.

2. Patent situation is not valuable for video self storage.

3. Some people doesn't need features like film grain.

4. SVT-AV1 gives better VMAF Y NEG and SSIM YUV 6:1:1 quality, but significantly [slower](https://www.compression.ru/video/codec_comparison/2022/10_bit_report.html) than VVEnc.

5. VVenc is faster and the same time gives better subjective quality than SVT-AV1 according to this extensive [comparison](https://www.compression.ru/video/codec_comparison/2022/subjective_report.html).

If you have links to another solid research, please share them.

These tests, like most benchmarks done by the "industry" have no value altogether. The normalization by speed is incredibly misleading. There is no "extensive comparison" to talk about with this biased test methodology. You didn't answer any of my arguments. How about you run your own comparisons and find out by yourself that what you are saying is wrong? Claiming that VVenC is faster without having ever run it once is quite bold.

[trixoniisama]

I will look into this. After I verify that I can encode/decode/mux and playback VVC with no issues. Last time I looked into this I couldn't remux and playback VVC.

You still can't with mkvmerge or in a mkv container at all for that matter.

[master-of-zen]

[thx4ever]

U can mux with mp4box with this command line options
mp4box -cat *.266 -new outfile.mp4
Also u can mux the audio and it works, i have tested it and it works in concatenating with mp4box, only there's a problem when using ratecontrol but crf works fine, and for playback u can use Media Player Classic Home Cinema https://github.com/clsid2/mpc-hc/releases/

[trixoniisama]

U can mux with mp4box with this command line options mp4box -cat *.266 -new outfile.mp4 Also u can mux the audio and it works, i have tested it and it works in concatenating with mp4box, only there's a problem when using ratecontrol but crf works fine

The point is that av1an doesn't support mp4 muxing and has no reason to.

[ioctl-user]

I will look into this. After I verify that I can encode/decode/mux and playback VVC with no issues. Last time I looked into this I couldn't remux and playback VVC.

Thanks!

I have tested these steps using ffmpeg patched with this patch set. However, for now vanilla ffmpeg cannot encode VVC, so standalone vvenc app or lib should be used.

[trixoniisama]

Av1an does not use ffmpeg's encoders anyway.

[thx4ever]

I added partial encoding to VVC, only --QP is supported because the current vvc implementation dont support mux with ratecontrol options when encoding in chunks, it encodes fine but when seek on playback crash the players, options like --TargetBitrate is not supported yet in VTM with chunking encode mode, there's one problem that i cant figure out if someone can help me fix it i will make a pull request
The progressbar and current frames dont update but encoding works as expected, i tried with regex like this

pub fn parse_vvc_frames(input: &str) -> Option {
let regex = Regex::new(r"vvenc [info]: stats: frame=(\d+)").unwrap();
regex.captures(input).and_then(|captures| {
captures.get(1).map(|match_| match_.as_str().parse().ok())
}).flatten()
}
but cant figure out why dont works, if someone can help here thanks

Regards