[QUESTION] About HLG Transfer and Bandicam

[RaienryuuNoNatsu]

Hi, I have a couple questions for you:

1. I've just read that a commit has been recently submitted to the x264 official project to support all new Transfers, included "ARIB STD-B67" (HLG), which is much easier to handle for YouTube purposes compared to "SMPTE ST 2084" (judging by their guide). As I'm using x264 as an external codec on Bandicam, are there plans to add that Transfer to this project as well?

2. This is my lack of knowledge, but I can't seem to find what I need. I wanted to record lossless footage for testing, so I used this command line: --qp 0 --range "pc" --colorprim "bt2020" --colormatrix "bt2020nc" --transfer "smpte2084"

As I prefer to do conversions manually, I set the RAW to PC range (as per my GPU settings and monitor), and wanted to record it in the RGB colorspace. Neither set "Prefer RGB colorspace" in the external codec selection, nor the "Keep/Accept only RGB" works. It just crashes. So, I have to "Convert to YV12", which works. What do you think may be the cause?

[MasterNobody]

Hi.

1. --transfer arib-std-b67 and --alternative-transfer <string> will be supported in the next version with updated version of libx264.
2. Do you mean real crash and not "Failed to initialize codec" message? May be you didn't disabled log in x264vfw configure? Bandicam don't like x264vfw's log window so better set Log level to None. Also for Bandicam I would recommend to set Zero Latency option to not lose few first frames (if you not going to use Output mode: File). Otherwise I don't have any problems with encoding in RGB with Keep/Accept only RGB or with Keep input colorspace+Prefer RGB colorspace.

Also if you going to encode in RGB better don't mess with options (range/colorprim/colormatrix/transfer) because that are incorrect values for RGB output (otherwise RGB input will be encoded as if it was YUV input i.e. with incorrect colors) and instead of --qp 0 simply set rate control to Single pass - lossless

[RaienryuuNoNatsu]

So first, thanks for the fast reply. I tried something before replying, so let me give you the full story. 1) That's good to know, it'll make handling YouTube stuff much simpler. Any ETA? 2) The log thing did the trick, and yes I use Zero Latency. You did a good job in sending logs. It did tell me to use it to not lose the first frames, as I'm having Bandicam handle outputting the file instead of x264.

…

-qp 0 is a sort of habit, I'll remove it as it's already set to Single Pass - Lossless. Ah, that's why I had wrong colours and always output YUV 4:4:4 instead of RGB. Now though I do have a question: this person who's gonna record the clip does have an 4K HDR TV, and he's gonna play something which supports HDR. Now, if I make him record in RGB (so, without setting matrix, primaries, and transfer), how can I be sure it is recorded correctly as HDR? Does that mean that RGB can tell the difference even without specifying all that stuff? If that's the case, I'll need to specify matrix, transfer, and primaries only after editing. Is that correct? 2018-01-04 21:54 GMT+01:00 Anton Mitrofanov <notifications@github.com>:

Hi. 1. --transfer arib-std-b67 and --alternative-transfer <string> will be supported in the next version with updated version of libx264. 2. Do you mean real crash and not "Failed to initialize codec" message? May be you didn't disabled log in x264vfw configure? Bandicam don't like x264vfw's log window so better set Log level to None. Also for Bandicam I would recommend to set Zero Latency option to not lose few first frames (if you not going to use Output mode: File). Otherwise I don't have any problems with encoding in RGB with Keep/Accept only RGB or with Keep input colorspace+Prefer RGB colorspace. Also if you going to encode in RGB better don't mess with options (range/colorprim/colormatrix/transfer) because that are incorrect values for RGB output (otherwise RGB input will be encoded as if it was YUV input i.e. with incorrect colors) and instead of *--qp 0* simply set rate control to Single pass - lossless — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AeDKIxK1mT6-s6VMB0TkKqDz2u1LKwNEks5tHTpqgaJpZM4RTOPe> .

[MasterNobody]

1. No ETA for new version;
2. I doubt Bandicam can capture in HDR (RGB or not) and afaik there no such thing as HDR RGB. Also HDR need at least 10-bit input (capture). This options do tell H.264 decoder which colorspace the encode is but x264vfw/libx264 do NOT convert input to such colorspace and only treat input as if it already converted. So when you say --colormatrix "bt2020nc" instead of default for RBG --colormatrix "GBR" your RGB signal is treated as if it was YUV BT.2020 signal (i.e. G->Y, B->U, R->V).

[RaienryuuNoNatsu]

Gotcha, that's all I wanted to know. I'll close the Issue myself. Thanks for the reply. 2018-01-04 23:15 GMT+01:00 Anton Mitrofanov <notifications@github.com>:

…

1. No ETA for new version; 2. I doubt Bandicam can capture in HDR (RGB or not) and afaik there no such thing HDR RGB. Also HDR need at least 10-bit input (capture). This options do tell H.264 decoder which colorspace the encode is but x264vfw/libx264 do NOT convert input to such colorspace and only treat input as if it already converted. So when you say --colormatrix "bt2020nc" instead of default for RBG --colormatrix "GBR" your RGB signal is treated as if it was YUV BT.2020 signal (i.e. G->Y, B->U, R->V). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AeDKI3mjeayetGY3VflIjpEbmuv8LlG1ks5tHU2VgaJpZM4RTOPe> .