Page 1 of 1

NVENC H.265 YUV 4:4:4 10-bit (lossless), and maybe Matroska (.mkv) container support

Posted: Sat Mar 30, 2019 8:21 am
by gdgsdg123
NVENC H.264 has a resolution limit of 4096x4096, which made it unfit to handle 8K. Leave alone its missing support for 10-bit.

And going to uncompressed solution is apparently not an option (do the math, the bitrate for 8K... SSD arrays? may work), while x264vfw (RGB) has performance issues (x264, or H.264 is designed for YUV colorspace, couldn't be effectively utilized when using RGB), and I can't seem to get it work with YUV 4:4:4 (bug?..). Anyway 10-bit for software encoding (realtime) seems unreal (performance limitation, unless you've got some ridiculous PC...). Retreat to 4:2:0? it defies the whole point (why not use lossy encoding then...), so...

NVENC H.265, but Bamdicam has limited its usage to lossy encoding only, while NVENC H.264 for the same container (.mp4) can use lossless. (what's the point?.. indeed H.264 is known to be more efficient handling lossless but...)



And maybe Matroska (.mkv) container support? just to save a few seconds remuxing...





References:
https://developer.nvidia.com/video-enco ... ort-matrix
https://developer.nvidia.com/nvidia-video-codec-sdk

Re: NVENC H.265 YUV 4:4:4 10-bit (lossless), and maybe Matroska (.mkv) container support

Posted: Sat Mar 30, 2019 8:27 am
by gdgsdg123
Forget to mention, to handle 8K, the 32-bit address space limitation appears to be another obstacle for Bandicam. (currently no Bandicam 64-bit)

Re: NVENC H.265 YUV 4:4:4 10-bit (lossless), and maybe Matroska (.mkv) container support

Posted: Wed Apr 03, 2019 5:28 pm
by Bandicam Company
Hello,

We will forward your request to the development team.

Thank you for suggesting it.

Another approach...

Posted: Tue Jul 16, 2019 8:22 pm
by gdgsdg123
Another approach to solve the dilemma... MagicYUV.
magicyuv.png
magicyuv.png (38.35 KiB) Viewed 11340 times
Its RGB24 encoding may yield similar (slightly worse) compression ratio than x264rgb (see below) but runs tens times faster (both encoding/decoding)...

Code: Select all

ffmpeg -i "INPUT_5120x1440@30" -c:a copy -c:v libx264rgb -preset placebo -qp 0 -x264-params "keyint=15:no-deblock=1" "OUTPUT.mkv"
  • The output generated in this manner is unplayable... (cannot be played realtime) (for the MagicYUV one... plays fine at least)
  • Caveat: It just happened to be a sample which happened to fail x264's inter-prediction... On a more common sample like this (lossless original) the above yields tremendous improvement on the compression ratio.

And x264rgb used in below manner ends in much bigger file and still significantly slower encoding:

Code: Select all

ffmpeg -i "INPUT_5120x1440@30" -c:a copy -c:v libx264rgb -preset ultrafast -qp 0 -x264-params "keyint=1" "OUTPUT.mkv"
  • And neither does it play (well... bad FPS).




While the YUV encodings of MagicYUV appeared much less impressive (fast though, just so so compression)... wondering why it's not called "MagicRGB".