Support forum for DG Tools

Not so long ago, the forum discussed the issue of command line compliance for x265 with ITU recommendations in the Chroma sample location alignment part.
viewtopic.php?p=11509#p11509
As I understand it, simply adding the --chromaloc 2 parameter for x265 does not actually convert the Chroma sample location. Therefore, if the original video file was created with ChromaLocType <> 2 (such 4K videos are quite common), then specifying the --chromaloc 2 option in the x265 parameters will not be correct, unless the actual conversion of the chroma sample location is done by the frame server itself.
I have a question, when decoding a source 4K video using DGDecNV, is the automatic conversion of the chroma sample location to type 2 performed?

Hello kliffgomel. Welcome to the forum!

No such conversion is performed. The video is decoded and delivered as is. Note that only 4:2:0 video (type 2) is currently supported by DGDecNV.

Sorry, I do not understand. DGDecNV only supports video decoding with chromaloc = 2? But what about video decoding with a different type of chroma sample location?

DGDecNV currently supports only 4:2:0 video. If you'd like to post a link to a sample, I can tell you if it is 4:2:0, and whether there is any prospect for it being supported. Everything depends on what NVDec can do. Ampere and some later Turing GPUs can decode HEVC 4:4:4. No nVidia GPU can decode 4:2:2. If your video is 4:2:2 you will need to use a SW decoder.

kliffgomel wrote: ↑

Fri Nov 06, 2020 2:09 am

ChromaLocType <> 2 (such 4K videos are quite common)

The ITU-T Recommendation specifies only Type 2 for YUV, so I doubt this. Please post a link to a sample and I can check it. If it is HEVC 4:4:4 then it may be possible to support it on later GPUs.

I am only talking about YUV 4: 2: 0 video. Can DGDecNV accurately decode YUV 4: 2: 0 (type 0) video, for example?
Link to test 4K video YUV 4: 2: 0 (type 0):
https://4kmedia.org/samsung-travel-with ... d-4k-demo/
Of course, I already checked DGDecNV here myself, decoding is possible. But in this case, my initial question arose. To ensure compatibility with ITU standards, I believe that when encoding it is necessary to convert chromoloc from type 0 to type 2. But for this it is not enough to simply specify the chromoloc = 2 option in the x265 parameters.

As best I can determine, CUVID/NVDec does not provide the chroma_loc_type to the application.Therefore, I write '--chromaloc 2' for the X265_CL line in the index file because that is the UHD bluray standard. You should edit that parameter as needed when creating your x265 command line for encoding. This does not affect decoding in any way. Streams will be correctly decoded regardless of chroma_loc_type.

I have the option of parsing the stream myself to get chroma_loc_type, but it is not a high priority for me and would be highly non-trivial.

There are no plans to do any conversion of chroma location sampling, e.g., to convert type 0 to type 2. You'll have to do that with some other tool.

I cannot download your sample because there are "too many users".

Still, a purely theoretical question, if you specify the '--chromaloc 2' option in the codec when encoding the source video YUV 4: 2: 0 (type 0), will this lead to errors when decoding the compressed output video?

Theoretically, yes, there will be chroma mislocation. It is widely considered to be perceptually insignificant for 4K resolution. There are some threads about it at Doom9.

In such a case, I would not add any codec options for specifying the chromaloc type unless I was completely sure that this option would match the original video. Perhaps, the command line option for the x265 codec, offered in the dgi index file, with the explicit setting of the '--chromaloc = 2' option, requires sensible use and is unsafe in some cases.
Anyway, thanks for the clarification!

It's just an aid for users to get started with their command line. I could have put '--chromaloc ?' instead and the user would always have to replace it with a valid number. But as DG tools are primarily disk-oriented I put a 2 in there. It's just as easy to edit 2 to something else as it is to edit ? to something else. The X265_CL does nothing unless the user chooses to copy it and use it to help in setting up their full command line. Anything can be dangerous when the user is clueless or stupid.