New to 4k hdr encoding, how to edit stuff and keep HDR ?

[r4dius]

Hi,

I've been using avisynth for years for normal 1080p edit / compression,
For the first time I need to edit some 4K HDR content and can't find the good way to use avisynth as input for x265, could you guys give some help ?

My avs is simple concat of 2 video parts, the "ConvertToRGB" function is required to crop with a number that's not multiple of 2,


loadplugin("dgdecodenv.dll")
video1 = dgsource("S:\Encode\source\war\video1.dgi")
video2 = dgsource("S:\Encode\source\war\video.dgi")

video1 = trim(video1, 0, 304)
video2 = trim(video2, 290, 2000)
video = video1 + video2

video = ConvertToRGB(video, matrix="Rec2020")
video = crop(video, 0,281,-0,-281)
video = ConvertToYUV420(video, matrix="Rec2020")

return video


My avisynth is avisynth+ 3.7.3
I manage to feed it to x265 like this:

avs2pipemod64.exe -y4mp video.avs | x265.exe --y4m --fps 24000/1001 --input-res 3840x1598 --frames 1000 - -o test.mkv

this gives me a video that looks "correct" except when playing in a HDR compatible player it plays without the HDR, it's dull / grey like an HDR file in a non compatible player

I'm not sure if it's something with my setup but x265 won't work with my avs as input, so had to use something like avs2pipe, I also tried to use "rawvideo" but it was giving a funny pixel mess :

avs2pipemod64.exe -rawvideo video.avs | x265.exe --fps 24000/1001 --input-res 3840x1598 - -o test.mkv

I have 0 knowledge of how HDR works, can't understand all those formats, is there something I'm missing in the commands / avs ?

In case there's some simple method to edit (cut and concat are required) HDR content and get it compressed with x265 please let me know too

Thanks

[FranceBB]

when playing in a HDR compatible player it plays without the HDR, it's dull / grey like an HDR file in a non compatible player



That's because you're missing the metadata about the primaries, matrix and transfer in your x265 command line. You should really check your source and add the relevant medatada. You can check them with Mediainfo or even in AVSPmod mod when you right click on the clip properties after indexing.

As an example, for PQ, you need to add

--colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc

while for HLG you need to add:

--colorprim bt2020 --transfer arib-std-b67 --colormatrix bt2020nc --atc-sei 18


if your source also specifies a MaxCll value, you should add it as well, especially for PQ like so --max-cll 1000,400 (this means 1000 nits with average 400 nits). If it doesn't say anything or you're not sure, don't put the MaxCll in. Although it used to be a mandatory metadata, most TVs managed to cope without it just fine.

[qyot27]

The more important question: when you play back the script in mpv (https://mpv.io/) (mpv input.avs), does it look [roughly] correct? If it does - meaning, the colors look more or less as they should on an HDR-aware TV - then it means mpv is seeing the HDR properties and tonemapping accordingly (with the caveat that tonemapping algorithms, OS-level HDR support, and interoperability with SDR or even HDR monitors is often just as much art as it is science when it comes to media playback, which is why I said 'roughly'). If it looks washed out, then something about the script is off.

One thing to note is that ConvertToRGB only works if the video is either 8-bit or 16-bit, does DGSource convert 10-bit input to 16-bit? Because otherwise that script will error out if it's anything other than 8-bit (which is a headscratcher for why HDR on just 8-bit content?). You can get 1-pixel crops with YUV444 as well, and that's way less potentially destructive than going to RGB and back.

If it does look correct, then the answer is simple:
ffmpeg -i input.avs -vcodec libx265 -crf XX -profile whatever -tune whatever -x265-params "key=settings:key2=settings" output.mkv
(use whatever your preferred bitrate mode/setting, profile, and whatnot are here)

You aren't mucking around with any of the HDR properties in the script and only using them as pass-through, so there's no chance of getting them wrong. FFmpeg will automatically set them for you on output if it sees them in the input, x265 CLI doesn't.

[r4dius]

That's because you're missing the metadata about the primaries, matrix and transfer in your x265 command line. You should really check your source and add the relevant medatada. You can check them with Mediainfo or even in AVSPmod mod when you right click on the clip properties after indexing.

As an example, for PQ, you need to add

--colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc

while for HLG you need to add:

--colorprim bt2020 --transfer arib-std-b67 --colormatrix bt2020nc --atc-sei 18


if your source also specifies a MaxCll value, you should add it as well, especially for PQ like so --max-cll 1000,400 (this means 1000 nits with average 400 nits). If it doesn't say anything or you're not sure, don't put the MaxCll in. Although it used to be a mandatory metadata, most TVs managed to cope without it just fine.

Thanks a lot I'll give this a try, I know it's PQ, seen it multiple times in stream info

[r4dius]

The more important question: when you play back the script in mpv (https://mpv.io/) (mpv input.avs), does it look [roughly] correct? If it does - meaning, the colors look more or less as they should on an HDR-aware TV - then it means mpv is seeing the HDR properties and tonemapping accordingly (with the caveat that tonemapping algorithms, OS-level HDR support, and interoperability with SDR or even HDR monitors is often just as much art as it is science when it comes to media playback, which is why I said 'roughly'). If it looks washed out, then something about the script is off.

One thing to note is that ConvertToRGB only works if the video is either 8-bit or 16-bit, does DGSource convert 10-bit input to 16-bit? Because otherwise that script will error out if it's anything other than 8-bit (which is a headscratcher for why HDR on just 8-bit content?). You can get 1-pixel crops with YUV444 as well, and that's way less potentially destructive than going to RGB and back.

If it does look correct, then the answer is simple:
ffmpeg -i input.avs -vcodec libx265 -crf XX -profile whatever -tune whatever -x265-params "key=settings:key2=settings" output.mkv
(use whatever your preferred bitrate mode/setting, profile, and whatnot are here)

You aren't mucking around with any of the HDR properties in the script and only using them as pass-through, so there's no chance of getting them wrong. FFmpeg will automatically set them for you on output if it sees them in the input, x265 CLI doesn't.

Thanks, didn't think about playing the avs in mpv, it's playing correctly, I have no idea about the bit formats output, I guess DGSource is 10 bit, I knew the avisynth was "OKish" because it played on virtualdub (no tonepammping) but I wasn't sure if it was in some sort of bad format at for something like x265,
I'll try your YUV444 method, as for x265 as you said I'm not touching anything except trimming / cropping / concat 2 video failes, I'll test with ffmpeg too and compare with direct x265,

Btw I found a x265 Mod by Patman version that accepts avs as input so it'll be simpler :)

Thanks guys

[r4dius]

Found this at the end of the video.dgi...

X265_CL --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50)" --max-cll "2508,2394" --frames 175204 --chromaloc 2

now I fill dumb :rolleyes:

[qyot27]

Btw I found a x265 Mod by Patman version that accepts avs as input so it'll be simpler :)
The AviSynth input module patches for x265 don't read the HDR information (simply as a matter of the fact that those patches are quite old, even if they've been kept synced with the x265 sources to continue building), and even if they did, AFAIK the x265 CLI always requires manually setting those properties rather than copying them over from the input.

[wonkey_monkey]

My avs is simple concat of 2 video parts, the "ConvertToRGB" function is required to crop with a number that's not multiple of 2

A better solution is surely to avoid doing an odd crop. Shift the image by one pixel (you can use bicubicresize/spline16resize etc, or my Warp plugin), then crop at even boundaries. That way you won't have to convert the colourspace at all.

[PoeBear]

z.lib can also odd crop without changing colorspaces

loadplugin("dgdecodenv.dll")
loadplugin("avsresize.dll")
loadplugin("FillBorders.dll")
video1=dgsource("S:\Encode\source\war\video1.dgi").trim(0,304)
video2=dgsource("S:\Encode\source\war\video.dgi").trim(video2,290,2000)
video1+video2
Crop(0,280,0,-280)
FillBorders(top=1,bottom=1)
z_Spline36Resize(3840,1598,0,1,0,-1)

[r4dius]

The AviSynth input module patches for x265 don't read the HDR information (simply as a matter of the fact that those patches are quite old, even if they've been kept synced with the x265 sources to continue building), and even if they did, AFAIK the x265 CLI always requires manually setting those properties rather than copying them over from the input.

Yes I meant I can use avs file as input in x265 command rather than some pipe, I still use the required values :)

[r4dius]

A better solution is surely to avoid doing an odd crop. Shift the image by one pixel (you can use bicubicresize/spline16resize etc, or my Warp plugin), then crop at even boundaries. That way you won't have to convert the colourspace at all.

z.lib can also odd crop without changing colorspaces

loadplugin("dgdecodenv.dll")
loadplugin("avsresize.dll")
loadplugin("FillBorders.dll")
video1=dgsource("S:\Encode\source\war\video1.dgi").trim(0,304)
video2=dgsource("S:\Encode\source\war\video.dgi").trim(video2,290,2000)
video1+video2
Crop(0,280,0,-280)
FillBorders(top=1,bottom=1)
z_Spline36Resize(3840,1598,0,1,0,-1)

Thanks guys I'll remove my colorspace conversion and use one of those

[r4dius]

Hi guys, I'm now getting a pretty good result on x265 with all your help, I'm still missing something about chapters,
I use to have qp files for x264 like this :
0 I -1
2979 I -1

I've read we need to force IDR frames on x265, it looks like the same syntax works, can you please confirm it's the same ?

Edit :
I started compression with the qpfile but getting vbv underflow warning :
x265 [WARN]: poc:17750, VBV underflow (-61107 bits)s

there's a chapter at frame 17752, I guess it's related, is this something I should care of ?

Edit 2 :
Ok i was adding the same 25600 VBV maxrate and bufsize values than handbrake to allow for dolby vision RPU metadata which comes with the source,
I changed to 40000 which is the default value for 5.1 main level and it looks like it's ok now