-
Notifications
You must be signed in to change notification settings - Fork 156
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
Comments
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. |
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. |
My considerations are the following:
If you have links to another solid research, please share them. |
I will look into this. |
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. |
You still can't with mkvmerge or in a mkv container at all for that matter. |
U can mux with mp4box with this command line options |
The point is that av1an doesn't support mp4 muxing and has no reason to. |
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. |
Av1an does not use ffmpeg's encoders anyway. |
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 pub fn parse_vvc_frames(input: &str) -> Option { Regards |
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 |
I can help only with testing, because don't know Rust :/ |
nice, make a PR |
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.
The text was updated successfully, but these errors were encountered: