FFMPEG - hevc_nvenc & h264_nvenc lossless presets not truly lossless?

[AnomalyDetected]

While working on a video conversion project, I've been storing some footage in lossless x264 and/or h264 encoded mkv files because they end up being about 10-15% smaller that storing frames as PNG's or using other lossless compression methods.

Using ffmpeg's libx264 or libx265 encoders with the "lossless" setting works fine, but naturally takes some time to encode. I can prove they are truly lossless by exploding the resulting mkv to bmp's and then comparing to the original source. The files are identical.

Using the h264_nvenc or hevc_nvenc encoders with the "lossless" preset is very fast, creates smaller files, and while the results look very good to the eye, when extracting frames to bmp's and comparing to source I can see they are not identical.

The syntax I as using is below. For libx265, which works but is slow:[LIST]
ffmpeg -i frame%04d.bmp -r 30 -c:v libx265 -x265-params lossless=1 movie.mkv
For hevc_nvenc, which quickly creates a good looking file, but appears to not truly be lossless:
ffmpeg -i frame%04d.bmp -r 30 -c:v hevc_nvenc -preset 10 -an movie.mkv
(I have tried some variations as well, such as "preset lossless" with no change)

To compare to original, I am simply running:
ffmpeg -i movie.mkv test\frame%04d.bmp
And finally running a file compare between like frames from source to compresses/uncompressed.

So are the "Lossless" presets of the nvenc encoders simply misnomers meant to indicate "close to original quality", or am I doing something wrong?

[poisondeathray]

BMP's are RGB. NVEnc does not support rgb24 , bgr24 or gbrp (ie. or any "RGB" derivative), only YUV444.

RGB=>YUV=>RGB is usually not a lossless conversion, unless the conversion is done at higher bit depth. So while you incur no additional compression losses, you still incur colorspace conversion rounding lossless

libx265 supports gbrp (and packed bgr24 to planar "gbrp" is losslessly inter-convertible)

[AnomalyDetected]

That's brilliant! Thanks so much. I'll have to read up on color space conversations.

It turns out my source video actually was in YUV420p already (which I was unwittingly converting into RGB24 when extracting to BMP frames for editing). So if I understand correctly, I could better preserve the color data by using TIFF as my intermediary format instead of BMP. But depending on the ultimate format I use for the video, I suppose I'll be doing an RGB conversion/esimation at some point anyway (even if it's only during decoding/playback).

Thanks again!

[poisondeathray]

TIFF supports YUV, but many applications will mishandle it . Why do you need an intermediate image sequence format ? What are you doing exactly ? There might be better ways to go about this

[AnomalyDetected]

Nothing secret, it's just not really my project to talk about is all. Some of the software we are using works only still images (in batches) so we have to explode our original source video to individual frames first for it to work on.

Out of curiosity, why doesn't NVENC support RGB24? It seems like that would be a very common thing people would want to do.

[Selur]

we are using works only still images (in batches) so we have to explode our original source video to individual frames first for it to work on.

side note: When importing rgb images and converting to yuv for the output make sure to take note of the color matrix and full vs. limited luma range during the rgb<>yuv conversion.
(same is true when exporting rgb images from yuv video)

Cu Selur