H265 Support

That’s all I need in my life. H265 with slow preset. Yessss

I agree having H265 would be a massive improvement.

1 Like

this is better done With NO GPU acceleration.

Dont know about ATI but Nvidia NVENC does not support b-frames in the h264/h265 encoding

I agree with CPU x265, but Nvidia NVenc has b-frame support now.

1 Like

NVENC Supports B-frames from GEN20 Encoders up and above. Careful, not all Turing cards have these encoders. The 1650 does not, it has the VOLTA Encoder.
Also, not all models offer the b-frame in the driver, when the nvidia encoder is used (provided in the SDK, I guess). While the 1660 HAS B-frame Support, using it via the NVIDIA Driver Encoder, it does NOT produce B-frames… Using nvencc works (in staxrip for example)…

Some smaller quadro und workstation cards also don´t have the video-encoder support with b-frames (or any at all, like the biggest datacenter number cruncher)…

An easy way to make a selection is: Everythin with RTX in its name, can produce b-frames in HEVC (as well as 10 Bit, 32 look ahead frames, etc…)

Rate Control is done in the driver, for those interested in better rate control, Mainconcept offers a “hybrid encoder”, which basically does a two way pass over NVENC frames and re-calculates them in case the rate control is off (Nvidia and AMD Encoeders are aimed for realtime streaming and similar, not for mastering video streams for production, so the don´t pay too muich attention in this field)…

2 Likes

x265 would be nice.
And for those not wanting to have the best quality possible, the hw-accell option (to use intel/amd/nvidia) would also come in handy (the options in ffmpeg are mostly compatible, so should not be too much trouble…)…

One thing to note: At the moment, b-frame support is broken on nvidia cards when called from ffmpeg…

With modern GPUs, the need for hardware-encoding is debatable - it´s not like VEAI would spit out 60fps in 4K and give the CPU a hard time encoding… And x265 “fast” is often as fast as the hardware-encoding, while not being worse in quality… But in some cases it would help to reduce stress on the CPU and gain some speed…

In terms of efficiencxy and qualirty, Iris XE Encoders are the best at the moment, in case someone is wondering (making even a small system a capable encoding thingy…)

1 Like

I wonder if we could consider AV1 coding

2 Likes

H.265 is a must. Without it the size of enhanced videos becomes unmanageable with the high output bitrates used by the application.

4 Likes

MUST have a choice of using NVENC or not. Would prefer the option not be there at all, but don’t force it on us.

beware, this one is much more work to implement than MKV :slight_smile:

just joking around…

NVEC would be totally useless for those without a NVIDIA card (like nearly every Mac for the last 10 years or so) and for older cards the quality is very poor as it targets live streams not recorded video. Support for all acceleration types is needed.

On the other hand x256 may actually be slow enough that it affects the rendering time but probably not by that much and is usually better quality for the same video bitrate.

You are correct, NVENC is only available on Nvidia Cards and varies with generation. All RTX named Cards and some GTX/Quadro/etc… from GEN 20 up with Turing and Ampere Encoder Units (NOT 1650 for example…) support B-frames in HEVC - which actually isn´t that bad in terms of quality… Still, software encoding is way better in terms of encoding efficiency… You already stated the reason: NVENC is designed for real time straming, not offline max-quality encodes.

AMDs newest encoders are also a little better than the previous ones, overall worse than Nvidia ones.

Intel actually has the best encoders nowadays - but those also don´t compete with software encoders when it comes to the absolute best encoding efficiency…

That said, I think there are two points worth mentioning:

  1. Encoding Hardware-acclereation for VEAI: It would make a lot of sense to support ALL plattforms… Sad thing is, that ffmpeg doesn´t offer everything in this case, b-frame support for nvenc HEVC is broken, AMD Encoders have some bugs and Intel I haven´t tried… The Nvidia suported encoders inside the drivers (the ones you get when toying with the CUDA toolkit) are also not optimal: Using a GTX 1660 for example lacks the b-frame suipport, although the card is able to do so (at least last time I tried a few weeks ago)… So VEIA would have to put a lot of work into this, either do some support on ffmpeg, rewrite some stuff, work closely with nvidia/amd/intel to get things up to level or go for 3. party encoder tools like nvencc (there are solutions that support everything needed - staxrip bundles all possible ones…)

  2. Quality / Speed / Ressources: Although hardware-encoding is not as efficient as software-encoding - it can deliever very good results, if enough bitrate is used… One will need more bitrate than with x26x --very slow presets to get to the same quality, but in cases where time is money and bandwith is not of the matter, this could be usefull… Lots of people using NLE Software are using these encoders and they are happy… Switching some of the heavy lifting of the encoding to the GPU can help a lot in some cases of not so big CPUs, freeing ressources for other stuff… On the other hand, regarding the slowdowns of x265 while outputting from VEAI: If one would go for very slow presets with a medium CPU, this actually could resoult in slowdowns for the whole prozess of VEAI upscaling and encoding. You are completely correct on this one… But with faster presets and decent CPUs, I see no problem… Its not like even a 3090 will be able to process 4K in realtime inside VEAI and be actually faster than x265 (again, given one doesn´t set a very slow preset or has a not powerfull enough CPU)… And I´d suspect that those of us wanting to get the maximung quality whatsoever are the ones doing the encoding seperately outside VEAI…At least I do it this way (distributet encoding on several machines, maxing out the cores)… So the majority will hover around default or fast presets, which should not bottleneck VEAI on a decent CPU… Comparing the faster presets in terms of efficiiency moves software encoding closer to the efficiency of good hardware-encoding - In some of my usecases (given enough horsepower on threadrippers for example), I can easily match the speeds of NVENC (-quality 2 passs presets, 32 frames lookahead) in software with faster presets…

TLDR: Its all about flexibility and options to chose from… I personally have other items on the top of my wishlist than hardware-encoding… But in case ffmpeg brushes up with the implementations and its not much more than passing on the correct output paramter inside VEAI, I wouldn`t mind having it as an option in VEAI for usecases where it makes sense (“oh, my deadline is soon, I need a HEVC File as fast as possible and only have 6 midrange cores feeding my 3080…”)…

Moving some of the filtering into hardware would be the next step, but this is discussed in another thread :slight_smile:

1 Like

@reiner You make a very solid point. However, implementing at least support for a custom encoder would be a huge step forward. Recently I dealt with increasing framerate in 1 episode of anime to 120 FPS. To prevent quality loss I had to go through uncompressed 16-bit TIF files that ended up taking 1.91 TB of space. A lot of the time I think the bottleneck was actually I/O related. Being able to export with full quality to a lossless HEVC video would save me both time and storage space. While NVENC can be broken in some way in FFMPEG, AFAIK lossless is not.

My vote also is “pro nvenc” :slight_smile:

losless AVC/HEVC gives some encoders headaches (nvenc and x26x), but all in all, it works of course… Limitations of ffmpeg apply to losless mode as well, not sure if other issues are present, haven´t played with it in a while. But losless AVC/HEVC it definitely can be a life saver in some case (like in your example)…

Exactly, in some of these situtations, hardware-encoding can be of help.

IF that will be the case in VEAI remains to be seen, since it often depends on the pipeline of the internal processing - I had cases where software-decoding and encoding was faster than hardware - not because the CPU was the biggest available and the GPU a very small one, but because of too much MEM swapping over the bus back and forth… x264 in very fast modes on a modern CPU is easily as fast as most hardware-encoders…

not sure if my point was clear… I was voting PRO hardware-encoding :slight_smile: