Does x265 encode natively RGB or does it internally do a YUV conversion?

[alatteri]

Hi not directly related to UG.

Does x265 encode natively in RGB when given a proper RGB 10/12 bit input, or does it still do a YUV conversion internally for the compression?

Thanks, Alan

[MartinPulec]

or does it still do a YUV conversion internally for the compression?

I am not aware that this is actually taking place. I've just tried:

$ uv -t testcard:c=R12L -c lavc:enc=libx265 --record=out:limit=2 # for some reason, mediainfo requires at least 2 frames
$ cat out/*h265 >out.h265
$ mediainfo --Output='Video;%ColorSpace%' out.h265
RGB

I don't remember that x265 converted RGB to YCbCr since we use/support it. IIRC just NVENC converted RGB to YCbCr (internally)?

[alatteri]

Hi Martin,

I received this from MulticoreWare, what do you think?

"x265 cannot directly accept RGB input files. It needs to go through a conversion using ffmpeg and sent as YUV 12 bit".

This doesn't seem accurate to me, and would definitely NOT be the first time, a manufacturer has given me rather wrong information about their own product.

The reason I ask, is if x265 is not RGB native pipeline throughout, then there would seem to be no advantage in regards to color accuracy over NVENC. It is very hard to get realtime, and even harder, low latency encode of UHD 12bit444 from CPU based x265. Whereas NVENC can do that without an effort.

Alan

[MartinPulec]

Well, I cannot tell how it is meant but I've just tried also:

 $ hevcesbrowser_console -i out/00000001.h265  | grep coeff
                                        matrix_coeffs = 0

0 should be RGB, so I don't have a reason to doubt about it. Maybe they think really input files, where there seem to be really only YUV files supported?

there would seem to be no advantage in regards to color accuracy over NVENC. It is very hard to get realtime, and even harder, low latency encode of UHD 12bit444 from CPU based x265. Whereas NVENC can do that without an effort.

I believe that NVENC supports just 10 bits. From UltraGrid point of view the advantage is also that the implementation of inra-refresh in x265 behaves nicely, whereas there were problems with NVENC - either a plusation, if we try to keep the bitrate variance small or vice versa the higher per-frame sizes' differencies (this may or may not be important for you, it is rather matter how sharp is the link bandwidth limited).

But generally speaking, if none of the above is problem for you, I'd also stick with NVENC.

[alatteri]

Hi Martin,

Thank you for taking a further look at this and providing the relevant links. Much appreciated.

I never implemented an NVenc workflow, for the reasons you outlined. Color accuracy for us is critical, so keeping a 12-bit RGB 444 pipeline, without the NVenc GOP pulse, is a clear x265 win. Also, past tests indicated that a UHD NVenc stream was difficult to decode in real time without a GPU, via CPU only. Since small hardware footprint is an important factor (Intel NUC), that makes NVENC not an ideal choice, although I have not tested playback of NVENC stream with the more recent NUC series 11/12/13. Additionally, our current encode machines are short depth 1U which can only accommodate 1 PCI card, so Decklink only, no room for GPU.

Unfortunately, the color issues with QSV_HEVC don't seem to have been resolved, so that also eliminates being able to use that hardware which does allow UHD encode/decode without much effort.

I've been able to finally get x265 to encode UHD RGB 12bit444@24fps in realtime, albeit by adding about 4-5 additional frames of latency via rc-lookahead,lookahead-threads,lookahead-slices, threads on Ryzen 7950X. There is not a lot of performance headroom left, but it's enough, although the additional latency is not ideal.

Anyway, thank you again for taking the time to look into this.

Alan