Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VVC support request #831

Open
ioctl-user opened this issue May 1, 2024 · 15 comments
Open

VVC support request #831

ioctl-user opened this issue May 1, 2024 · 15 comments

Comments

@ioctl-user
Copy link

ioctl-user commented May 1, 2024

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
Copy link

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
Copy link

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
Copy link
Author

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
Copy link
Owner

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
Copy link

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
Copy link

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
Copy link
Owner

image

@thx4ever
Copy link

thx4ever commented May 4, 2024

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
Copy link

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
Copy link
Author

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
Copy link

Av1an does not use ffmpeg's encoders anyway.

@thx4ever
Copy link

thx4ever commented May 7, 2024

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

@thx4ever
Copy link

I have added vvc support but the frames encoding percentage i dont know why dont work, i have attached the source code if someone can find out the problem
Av1an_ultimo_refactor.zip

@ioctl-user
Copy link
Author

I have added vvc support but the frames encoding percentage i dont know why dont work, i have attached the source code if someone can find out the problem Av1an_ultimo_refactor.zip

I can help only with testing, because don't know Rust :/

@KonstantinDjairo
Copy link

I have added vvc support but the frames encoding percentage i dont know why dont work, i have attached the source code if someone can find out the problem Av1an_ultimo_refactor.zip

nice, make a PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants