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

[benwaggoner]

Originally Posted by Selur

'AAC True VBR mode' https://github.com/nu774/qaac/wiki/Command-Line-Options
https://wiki.hydrogenaud.io/index.ph..._AAC#afconvert
There have been some discussions over at HydrogenAudio about whether vbr or tvbr are better.

Ah. So "vbr" there is a CVBR (Constrained VBR) ala setting --crf with a --vbv-maxrate and --vbv-bufsize. That's going to be preferable for streaming and combined video/audio delivery, as peak bitrates worst case can be defined. We need that for video as profile/level define a maximum bitrate for compatibility which we want to stay under.

TVBR would be an uncapped VBR, ala just using --crf or --qp without any profile/level VBV limitations. Potentially slightly better sound quality, and preferable for file-based playback.

Since there's only so high a bitrate can go with a codec, in practice there's not likely to be that much a difference unless the constrained bitrate is quite constrained.

[kurkosdr]

Originally Posted by benwaggoner

100 Kbps can matter if targeting mobile devices, and xHE-AAC decode is effectively universal on mobile: Android, iOS, and Fire OS have all supported xHE-AAC decode for a couple of replacement cycles now.

And with new codecs like VVC, we can push video bitrates down enough that audio becomes an increasingly large part of the total payload.

As long as xHE-AAC stays away from video broadcast (DVB and ATSC), I am happy. Streamers can always encode an HE-AAC fallback for older devices and serve accordingly (I don't like the idea of throwing away good smartphones in the name of "replacement cycles"/planned obsolescence, I still use my Nexus 5 and 5X as secondary phones). Although on streaming you won't save 100kbps but 30kbps (in our example above) because you are not streaming all 3 languages (audio streams) simultaneously like you do on broadcast. So, I highly doubt the usefulness of it, but as long as they provide a fallback (as they do usually), it's not an issue.

[MoSal]

Originally Posted by kurkosdr

As long as xHE-AAC stays away from video broadcast (DVB and ATSC), I am happy. Streamers can always encode an HE-AAC fallback for older devices and serve accordingly (I don't like the idea of throwing away good smartphones in the name of "replacement cycles"/planned obsolescence, I still use my Nexus 5 and 5X as secondary phones). Although on streaming you won't save 100kbps but 30kbps (in our example above) because you are not streaming all 3 languages (audio streams) simultaneously like you do on broadcast. So, I highly doubt the usefulness of it, but as long as they provide a fallback (as they do usually), it's not an issue.

This whole discussion was weird, since it managed to ignore the two facts that:

1- Opus exists.
2- Audio codecs don't need hardware (accelerated) support. Platform-level support is not an absolute requirement either. Apps can add software decoding for any audio codec without a noticeable downside like too much battery drainage (assuming no unusual complexity requirements).

There is a reason why xHE-AAC is not that exciting.

---

There is a third fact that HE-AAC is shit for anyone who has any respect for their ears. But let's not get into that.

[benwaggoner]

[QUOTE=kurkosdr;1999619]As long as xHE-AAC stays away from video broadcast (DVB and ATSC), I am happy. Streamers can always encode an HE-AAC fallback for older devices and serve accordingly (I don't like the idea of throwing away good smartphones in the name of "replacement cycles"/planned obsolescence, I still use my Nexus 5 and 5X as secondary phones).[QUOTE]
xHE-AAC is supported on really old phones. As long as it can upgrade to Android 9 or iOS 13, the decoder is there. That's all the way back to the iPhone 6s for Apple. Android updates are up to the whim of the OEM, of course, but five years is enough to get a pretty complete ecosystem refresh for mobile. Certainly most streaming apps don't support OS versions earlier than those.

But yeah, for broadcast broadcast, introducing new codecs is fraught and generally part of a massive shift. ATSC 1.0 to 3.0, for example (which still exists more in theory than practice). DVB seems to be able to get an update in more than once every few decades .

Although on streaming you won't save 100kbps but 30kbps (in our example above) because you are not streaming all 3 languages (audio streams) simultaneously like you do on broadcast. So, I highly doubt the usefulness of it, but as long as they provide a fallback (as they do usually), it's not an issue.

There are several big benefits of xHE-AAC for streaming

1. Seamless switching between all bitrates. That wasn't supported between LC and HEv1 or HEv1 and HEv2.
2. Single codec scalable from perceptually lossless music down to very low bitrate speech
3. Better speech quality in general at lower bitrates
4. Better compression efficiency than any legacy AAC variant at any given bitrate or perceptual quality threshold.

[birdie]

MPC-HC 2.2.0 by clsid2 now supports VVC decoding natively, hooray!

https://github.com/clsid2/mpc-hc/releases

Probably uses native FFmpeg decoding which is far from being fully/properly optimized (vvdec is 2-3 times faster) but it's still freaking amazing.

[TDS]

I'm not sure if I'm in the correct thread, but I'm trying to use this VCC Encoder:-

https://github.com/Disa-Kizonda/VVC-GUI-Encoder

And after setting up the "Ready to Use Pack", and loading a file, I get this error:-

'ffmpeg_vvceasy.exe' is not recognized as an internal or external command,
operable program or batch file.
Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.9_3.9.3568.0_x64__qbz5n2kfra8p0\lib\tkinter\__init__.py", line 1892, in __call__
    return self.func(*args)
  File "C:\Users\Geoff\Downloads\VVC_GUI_Encoder\VVC_GUI_Encoder.py", line 10, in SelectButton
    imgone=Image.open('temp.jpg')
  File "C:\Users\Geoff\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.9_qbz5n2kfra8p0\LocalCache\local-packages\Python39\site-packages\PIL\Image.py", line 3277, in open
    fp = builtins.open(filename, "rb")
FileNotFoundError: [Errno 2] No such file or directory: 'C:\\Windows\\System32\\temp.jpg'

'C:\\Windows\\System32\\temp.jpg' this doesn't look right, either...

double \\ ???

[LigH]

Regarding the double backslash: I am almost sure this is not the problem, just a required convention on Windows; but expecting a temporary JPEG file in Windows\system32 is an issue: No application should try to create files there. I guess the converter searches there for a file it did not find elsewhere, maybe because a verbose path to that file is missing. Searching alternatively in the system directory of Windows may be fine when looking for required DLLs, but not when looking for general data files.

Also note:

'ffmpeg_vvceasy.exe' is not recognized as an internal or external command, operable program or batch file.

Your package might be incomplete. Or it is not set up correctly with verbose paths to find the used tools.

[LigH]

Looking for "VVC encoder GUIs", I also found this project which might be interesting for some Linux users:

aviator - https://github.com/gianni-rosato/aVVCator
A Flatpak-first easy-to-use GUI for encoding with VVenC & aac.

[TDS]

Originally Posted by LigH

Looking for "VVC encoder GUIs", I also found this project which might be interesting for some Linux users:

aviator - https://github.com/gianni-rosato/aVVCator
A Flatpak-first easy-to-use GUI for encoding with VVenC & aac.

I need something pretty easy to use, don't like CLI stuff.

This one looks interesting:-

https://github.com/MartinEesmaa/VVCEasy

[birdie]

Please exercise extra caution when using random github projects or anything you download from the Internet.

In a perfect world you either run such things under a separate limited user account (given your system is 100% up to date/still supported/fully updated), or better yet in a virtual machine (virtualbox, vmware, qemu/kvm, etc), again under a limited user account.

The same applies to various PPA/COPR/AURs/whatever.

[TDS]

Originally Posted by birdie

Please exercise extra caution when using random github projects or anything you download from the Internet.

In a perfect world you either run such things under a separate limited user account (given your system is 100% up to date/still supported/fully updated), or better yet in a virtual machine (virtualbox, vmware, qemu/kvm, etc), again under a limited user account.

The same applies to various PPA/COPR/AURs/whatever.

Most of that didn't make any sense to me at all...

What do you suggest I use, that is an easy to use GUI ??

[birdie]

And now FFmpeg 7.0 as well!

"A new major release, FFmpeg 7.0 "Dijkstra", is now available for download. The most noteworthy changes for most users are a native VVC decoder (currently experimental, until more fuzzing is done)"

Originally Posted by birdie

MPC-HC 2.2.0 by clsid2 now supports VVC decoding natively, hooray!

https://github.com/clsid2/mpc-hc/releases

Probably uses native FFmpeg decoding which is far from being fully/properly optimized (vvdec is 2-3 times faster) but it's still freaking amazing.