My computer is on 24/7 (two of them), both running various tasks all the time, so there is no “extra” electricity being used. NVENC makes files that are quadruple the necessary size at the same bitrate compared to CPU. End of debate for me.
Same for me. Sure, you can get a cheap 6T drive. Having a proper, dedicated NAS, however, is a different story. Then you’re suddenly looking at near $2,000 in quality drives (and a near equal amount of that for backup).
My i9 12900K does draw ca 250-300W permanently, when doing a full x265 encode on P-cores only. So, yeah, electricity cost is a real thing. Then again, doing VEAI pulls ca 350W for my GPU too. There’s simply no such thing a a free lunch.
I have re-encoded UHD movies that are near 100G already; having those grow to 2-4x their size, because of lazy HVENC, is insane, though.
I don’t have anything over 8GB, even at high quality 4K
The ‘problem’ with VEAI is that it’s catered too much towards Mac users, LOL. No, seriously, Mac users just set to ProRes422 HQ, and don’t worry about anything else.
H265 output is different, though. You want fine-grained control over its parameters, and (like with H264 output) you’re not going to get that. Tl;dr: I don’t trust VEAI to get it right; aka, I trust them to create some sort of bland, mainstream H265 profile that doesn’t produce horrible results, but with no user control over quality.
So, I would like to see a lossless HEVC output, like for H264; if for nothing else, because its output size is smaller (HEVC was specifically made to deal with the idea of keeping the output size of 4K material in check). So, HEVC is pretty much a must.
But what we really need, I think, is a 10-bit color output format, both for H264 and H265. The current H264 output format (mp4) is only 8-bit. What we need is yuv420p10 support on H264/H265. And H265 to begin with.
I absolutely agree that a 10-bit lossless option should be available in a codec. Also on the latest GPUs yuv444p16le is a supported pixel format so I can drool over that as well
We’re actually alpha testing the 3.0 of Veai, and H265 is supported.
The ProRes 422 format practically is lossless because pretty much any re-encoding will be done with chroma subsampling anyway. And unless you have a special case you will encode it with 420 subsampling so it’s even “better than lossless”, for re-encoding and mastering purposes anyway.
And the ProRes 422 format is already ridiculous enough that you pretty much need a dedicated hard drive to store it.
Of course supporting 444 couldn’t hurt, they can also add 420 support while they are at it, which would be the most sensible option for a temporary mastering format in out use case.
Problem with ProRes, for me, it still that it’s too Apple-oriented. In practical terms, this means you even have a hard time finding a Windows tool to play the file with (other than bloatware such as QuickTime), or professional programs like Davince Resolve. But even the latter apparently can’t do something as simple as copy a frame to clipboard (!), to check the height of black bars or some such.
Lossless H265 will also produce huge files, but is a lot more PC-tools friendly. Good thing they decided to implement it. So, the point is kinda moot.
I had no problems open it, I think all ffmpeg based software can handle ProRes. Had no problem with Avidemux, Handbrake and Staxrip.
Perhaps it’s just Apple who invented the format but others also implemented it.
Vaei Could detect card on install.
H265 10bit And 12bit.
For what purpose? Capability check is done at each startup.
VEAI does not need need to be Nvidia.
Could you elaborate? What do you mean ?
I fully support your request for H.265/HEVC as a video encoding option in a future VEAI release, it’s a great idea and H.265’s higher encoding quality, efficiency (reduced size for same quality vs. H264) coupled with its genuine support for true HDR and WCG video files at 4K-UHD and higher resolutions all make it a seriously needed new VEAI video encoding option to maximize user storage space efficiency and video export quality and compatibility with future player software and hardware devices.
I also really hope that if the H.265/HEVC codec is included in a future VEAI version that it would use the already well-into-development public, free and open-source software (FOSS) implementation of the H.265/HEVC video encoding scheme: “x265”, made by many of the same members of the fantastic FOSS media file format standards community developers responsible for .OGG/.OGV, and the FOSS x264 implementation of the H.264 encoding scheme.
Additionally, I really would like to see the full user customization options and quality parameter values opened up to users of VEAI by giving us an “advanced” settings sub-menu visible when choosing our VEAI video project exported file characteristics so we can fine-tune the encoder(s) to use exactly the quality settings we desire for a given VEAI export file, saving a ton of time later by eliminating the need for users to re-encode a video exported from VEAI in, say, x264 format, into x265 format after the fact.
Because VEAI does open and process HVEC, I’m guessing this thread is only about being able to set the output to it.
I agree that it makes the most sense. The most common use case for VEAI is upscaling and enhancing. Both those actions tend to make video files bigger. HVEC would mitigate that.
What if they skip HVEC and add output in like AV1 or VVC?
AV1 is great I can say. But it’s not ready for prime time.
New to the Forum so please be gentle
I’ve got an M1 Mac mini with 16Gb Ram, which enhances a 45 min SD 720x576 video into a 125% 960x720 HD (4:3) at the rate of 0.13 sec/frame Using Low quality and Artemis Low quality. (I think that’s everything?)
I get a great result with the video sharpened and cleaner, more natural, colours.
The one thing that would make it better would be x265 encoding.
At the moment I run the 2.85Gb file through Handbreak and reduce the file to 1Gb without any obvious (to me) signs of loss of quality. It takes only 2 mins.
How difficult it would be to add x265 support and would it significantly increase the time?
Render time, no it should not affect it too much assuming theres no contention between the GPU / Neural Engine usage and CPU usage or GPU / Neural Engine and whatever they call the video codec piece of the M1.
CPU encoding using ffmpeg to encode using x265 , the current version of x265 does 7 frames per second at crf 23 on a much larger res file (2538x1080), the current development version does 23 fps on the same file.
Using hardware accelerated encoding from videotoolbox, again using ffmpeg to encode, with a bitrate equivalent to that output from x265 ( -b:v 2366k) was 136 frames per second.
Hmmm thats interesting, just had a poke around in the VEAI package to see have they where using to do the encoding…
EDIT: I’ve have a bit more of a think about it… and changed the wording in the following paragraph…
So it theory the minimum they would need to do is change the -v:c setting they throw it at assuming they do actually use that for the encoding. They’d probably want to change the CRF slider to different values.
Even more interesting, it has x265 configured in there…
configuration: --prefix=/Users/gregory/vargol-ffmpeg/out --enable-static --enable-gpl --pkg-config-flags=–static --pkg-config=/Users/gregory/vargol-ffmpeg/tool/bin/pkg-config --enable-libaom --enable-libopenh264 --enable-libx264 --enable-libx265 --enable-libvpx --enable-libmp3lame --enable-libopus --enable-neon --enable-runtime-cpudetect --enable-audiotoolbox --enable-videotoolbox --enable-libvorbis --enable-libsvtav1 --enable-libass --enable-lto --enable-opencl
libavutil 57. 17.100 / 57. 17.100
Oh and even more interesting (to me at least)
That suggests they are using my build script, or a fork of it, to build ffmpeg for the M1 so they have access to the 23 fps version (actually 21 fps if they are using the master branch, the 23 fps version is in the other branch)
Thanks very much for the reply. It looks like we could be seeing x265 in the future then!
I’m a total noob so I appreciate your time.