Is there a simple way to conserve HDR10 through adobe/handbrake?

[BobbyBoberton]

Hey there,

I have been trying to learn how to conserve HDR10 metadata that a film/file already has on it but I haven't found a good answer.

The most certain answer I have found is to take the original UHD and transcode to DNxHR then use 3DLut plugin through davinci resolve 15/16 to create a tone map and then use davinci resolve 15/16 to combine the tone map with the original video stream and export again as DNxHR (which is HUGE, like 700GB huge, so we are talking 1.4 TB just for the middle workflow) and then finally encoding that DNxHR file into HEVC 10-bit HDR10.

There is also a person that claims that they get HDR10 conserved by using this FFmpeg script/code:

ffmpeg -hide_banner \
-i "../storage/My.Source.Movie.2019.2160p.BluRay.REMUX.HEVC.DTS-HD.MA.TrueHD.7.1.Atmos.mkv" \
-pix_fmt yuv420p10le \
-max_muxing_queue_size 9999 \
-map_chapters 0 \
-metadata title="My Awesome Movie (2019)" \
-map 0:0 -metadata:s:v:0 language=eng -metadata:s:v:0 title="My Awesome Movie (2019)" \
-metadata:s:t:0 filename="" -metadata:s:t:0 mimetype="image/jpeg" \
-c:v libx265 -preset fast \
-x265-params crf=18:no-sao=1:aq-mode=3:max-merge=4:keyint=60:bframes=3:repeat-headers=1:colorprim=bt2020:transfer=smpte2084:colormatrix=bt2020nc:master-display="G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,500)" \
My.Movie.2019.2160p.BluRay.REMUX.HEVC.DTS-HD.MA.TrueHD.7.1.Atmos.mkv

but I have to compile a FFmpeg myself for windows so that it includes libx265 (I can definitely do this, I just don't want to stop the encoding jobs I have going to try this out right this moment) and all the extras. I am aware of the autobuild that was put together for this purpose so I am looking into that but supposedly handbrake is not able to conserve HDR10 data even with the extra settings of:

hdr:max-cll=4000,1000:master-display=G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1):deblock=-2,-3:strong-intra-smoothing=0:sao=0:hdr-opt

using HEVC 10-bit main 10 encoder, I am told this has something to do with the handbrake workflow being only 8-bit at some point therefore it is not able to properly conserve HDR10 metadata.

Can anyone give me any advice on whether the FFmpeg script above will conserve HDR10 metadata (I know the script is just video, I can easily mux together the audio after the video encodes) before I try it for myself?

If not can someone either point me to a thread that goes through how to extract the HDR10 metadata from a UHD file and then re-encode the base video and tone map? The person that posted the info I found on redfox.bz was evidently made into a video that was over 2 hours long to explain the workflow but the video is no longer available and the author stopped replying over 2 years ago now.

I can't even get the HDR10 metadata conserved on personal video shot with my Samsung Note10+, if I try to re-encode in anyway the HDR10 info is gone. It's still 10-bit BT.2020 SMPTE ST 2086 HDR10 'compatible' but the HDR10 metadata is gone.

I have been looking for an answer to this for a long time, please help point in the right direction if its not too much trouble.

Thanks for your time.

EDIT: I went ahead and compiled my own FFmpeg for windows with all the extra's and it 'seems' to conserve the HDR10 tags on UHD video but I would still like to hear from community members as to what you do personally to conserve HDR10 metadata in a UHD HDR10 video taken, like I said, for instance, from my Samsung Note10+.

Thanks

[benwaggoner]

I believe Zeranoe's GPL builds include x265. That might be simpler for you.

https://ffmpeg.zeranoe.com/builds/

I'm not quite parsing that script mentally. The metadata is in SEI messages in the elementary stream, so those could be copied forward. Alternatively it could be read from the file with MediaInfo or whatever and then those values specified in the x265 parameters. The static 2086 metadata (NOT HDR10+) shouldn't vary across a title.

If you are preserving HDR, a tone mapping step shouldn't be needed. If you're changing the color volume or adjusting video levels, you're changing the metadata and will need to calculate new values. What is your actual source?

[excellentswordfight]

I'm not sure if I understand the issue, just set the flags that matches the source in your re-encode? I dont understand why you wanna add tone map in the mix? I dont use handbreak though, but I have a hard time believing that newer versions cant handle 10bit input properly.

These are the relevant HDR10 metadata flags in x265 (max-cll and master-display values may differ from source to source), and you can just "extract" them by using mediainfo.

--colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --max-cll "1000,400" --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)"

If you dont want to compile ffmpeg, just use an zeranoe build, they include x265 and are publicly available.

[benwaggoner]

Originally Posted by excellentswordfight

I'm not sure if I understand the issue, just set the flags that matches the source in your re-encode? I dont understand why you wanna add tone map in the mix? I dont use handbreak though, but I have a hard time believing that newer versions cant handle 10bit input properly.

These are the relevant HDR10 metadata flags in x265 (max-cll and master-display values may differ from source to source), and you can just "extract" them by using mediainfo.

If you dont want to compile ffmpeg, just use an zeranoe build, they include x265 and are publicly available.

Master Display paramaters themselves can change when a different mastering monitor is used. There was pretty much just the one Sony model for the early years of HDR, but we're seeing some more options now.

That said, I'm not aware of any displays doing anything with the mastering display metadata. MaxCLL is the most used.

[BobbyBoberton]

Originally Posted by excellentswordfight

I'm not sure if I understand the issue, just set the flags that matches the source in your re-encode? I dont understand why you wanna add tone map in the mix? I dont use handbreak though, but I have a hard time believing that newer versions cant handle 10bit input properly.

These are the relevant HDR10 metadata flags in x265 (max-cll and master-display values may differ from source to source), and you can just "extract" them by using mediainfo.



If you dont want to compile ffmpeg, just use an zeranoe build, they include x265 and are publicly available.

I did compile FFMpeg myself, I just didn't want to interrupt the 50+ files I had in queue in handbrake, and no, if I sent colorprim, transfer, colormatrix, master-display, max-cll in handbrake (using x265 main 10) it will spit out a file with those 'HDR tags' but the colorprim/colormatrix is set to bt.709 even if I specify smpte2084 in the extra opts.

I don't want to bring in the tone mapping stuff if it is not necessary, it is just the best info I have bee able to find or been told on other forums for preserving HDR10 metadata.

If I run a video that I shot from my phone through my nVidia shield on my TV it will go into 'HDR' mode but if I run it through handbrake with all the correct options set,

(options being: crf=23:no-sao=1:aq-mode=3:max-merge=4:keyint=60:bframes=3:repeat-headers=1:colorprim=bt2020:transfer=smpte2084:colormatrix=bt2020nc:master-display="G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,500)":strong-intra-smoothing=0:hdr10=1:deblock=-2,-3)

and then play that reencoded file on my TV through the same means it does not pick up any 'hdr' info and just plays and an SDR video.

I have gotten CLI FFmpeg working, I will see if using that properly conserves HDR metadata, but, what I am hearing from you is that I should not go down the road of using UHD.mkv -> DNxHR -> 3dLut with DaVinci Resolve -> export DNxHR with lut applied -> reencode to HEVC. This seemed like a ton of work for something that is relatively simple, its not like its HDR10+ dynamic metadata, so I thought there should be a simple way to do it.

[BobbyBoberton]

Also can someone advise me why I cannot set the profile to Main10 for the CLI version of FFmpeg when I just used it to encode some 4k video without issue. I know that that the hdr10=1 and other tags would auto trigger this profiles use but when I try -profile:v main10 before -x265 params but after -c:v libx265 it doesn't give any errors but the encode still says using main profile, not main 10. Also setting -x265-params profile=main10 or profile="main10" I get a profile option not found error and it defaults back to main.

this is the command I used:

ffmpeg.exe -hide_banner -i "D:\Convert\Home.Movie.1080p.HDR.mkv" -max_muxing_queue_size 9999 -map_chapters 0 -metadata title="Awesome Show E01" -map 0:0 -metadata:s:v:0 language=eng -metadata:s:v:0 title="Awesome Show E01" -metadata:s:t:0 filename="" -metadata:s:t:0 mimetype="image/jpeg" -c:v libx265 -preset medium -profile:v main10 -x265-params max-cll="1000,400":crf=23:no-sao=1:aq-mode=3:max-merge=4:keyint=60:bframes=3:repeat-headers=1:colorprim=bt709:transfer=bt709:colormatrix=bt709:strong-intra-smoothing=0:deblock=-2,-3:range="limited":me="star" "D:\Converted\Home.Movie.1080p.10-bit.no_audio.mkv"

not sure what I am doing wrong, I could convert it with handbrake to 10-bit for sure but I would rather get use to the CLI version. Does it have anything to do with the colorprim,transfer,colormatrix stuff I have?

Thanks


EDIt: didn't expect this to post so if mod sees it can you release the message i replied with before this one? Thanks, its in reply the first and second reply.

EDITEDIT: I should say the settings that auto triggered the main10 profile was:

ffmpeg.exe -hide_banner -i "D:\Convert\Home.Move.HDR.Samsung.Note10+.mkv" -pix_fmt yuv420p10le -max_muxing_queue_size 9999 -map_chapters 0 -metadata title="My Awesome Movie (2019)" -map 0:0 -metadata:s:v:0 language=eng -metadata:s:v:0 title="My Awesome Movie (2019)" -metadata:s:t:0 filename="" -metadata:s:t:0 mimetype="image/jpeg" -c:v libx265 -preset fast -x265-params max-cll="1000,400":crf=23:no-sao=1:aq-mode=3:max-merge=4:keyint=60:bframes=3:repeat-headers=1:colorprim=bt2020:transfer=smpte2084:colormatrix=bt2020nc:master-display="G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,500)":strong-intra-smoothing=0:hdr10=1:deblock=-2,-3 Home.Movie.HDR.Samsung.Note10+.mkv

[Blue_MiSfit]

-pix_fmt yuv420p10le is the key

[BobbyBoberton]

Originally Posted by Blue_MiSfit

-pix_fmt yuv420p10le is the key

Um ok, maybe I misunderstood the documentation but I thought -pix_fmt was to explicitly tell FFmpeg what the format of the incoming file, not the output format, but I guess that makes sense because if I drop the -pix_fmt yuv420p10le then it defaults to yuv420p so ok, thank you.

[benwaggoner]

Originally Posted by BobbyBoberton

Um ok, maybe I misunderstood the documentation but I thought -pix_fmt was to explicitly tell FFmpeg what the format of the incoming file, not the output format, but I guess that makes sense because if I drop the -pix_fmt yuv420p10le then it defaults to yuv420p so ok, thank you.

I think it specifies the internal color space. yuv420p10le needs to get set for any HDR work, for example.

[nevcairiel]

Originally Posted by BobbyBoberton

Um ok, maybe I misunderstood the documentation but I thought -pix_fmt was to explicitly tell FFmpeg what the format of the incoming file, not the output format, but I guess that makes sense because if I drop the -pix_fmt yuv420p10le then it defaults to yuv420p so ok, thank you.

It depends where you put the option. And what kind of file it is.

If you want to specify any properties for the input file, you need to put them before the -i option. Anything after the -i option specifies the output.

An MKV file with presumably h264 or h265 inside, you cannot override the "incoming" format anyway, the encoded bitstream clearly defines that, so that isn't often useful.

So yeah, you are specifying the output format, which is going to be passed to x265. Although if your input was already 10-bit, it should've just stuck with that. So your input must've been something else then?

[BobbyBoberton]

Originally Posted by nevcairiel

It depends where you put the option. And what kind of file it is.

If you want to specify any properties for the input file, you need to put them before the -i option. Anything after the -i option specifies the output.

An MKV file with presumably h264 or h265 inside, you cannot override the "incoming" format anyway, the encoded bitstream clearly defines that, so that isn't often useful.

So yeah, you are specifying the output format, which is going to be passed to x265. Although if your input was already 10-bit, it should've just stuck with that. So your input must've been something else then?

Yes that issue was going from 1080p 8-bit to 1080p 10-bit, after using -pix_fmt yuv420p10le it worked out fine so you're all right. Also, the bitstream defining the incoming format makes sense, I guess I wasn't thinking too critically about it. I was only messing around with the encoder for this portion because I found a post from someone saying that encoding in 10-bit vs 8-bit even if the source is 8-bit will compress better (assuming smaller file size is meant by this) without loss of quality with the exact same encoder settings, I haven't found this to be generally true, for the files I tried it on the 10-bit version was usually about 10-15MB larger but then I found if I turn on hevc-aq and use 10-bit pixel depth I get at least 25% smaller file sizes that do not look discernably better or worse than the larger file. Not sure why that would be but I know hevc-aq disables all other aq-modes so perhaps hevc-aq should be enabled by default if running libx265 encode? Just a thought.

EDIT: So the original was yuv420p and without explicitly setting pix_fmt to yuv420p10le it defaulted to the same colorspace as the input stream

[Asmodian]

Originally Posted by BobbyBoberton

I was only messing around with the encoder for this portion because I found a post from someone saying that encoding in 10-bit vs 8-bit even if the source is 8-bit will compress better (assuming smaller file size is meant by this) without loss of quality with the exact same encoder settings, I haven't found this to be generally true, for the files I tried it on the 10-bit version was usually about 10-15MB larger but then I found if I turn on hevc-aq and use 10-bit pixel depth I get at least 25% smaller file sizes that do not look discernably better or worse than the larger file.

This is not a good way to figure out this relation. You do not actually get the same quality with the same settings when you change the bitdepth. You are comparing files with different quality and different sizes, which makes it very hard to learn anything.

Ideally you would use a two pass encode while testing so the files were the same size and you can judge them on quality. To do this you also need to compress enough that you can judge differences in quality.

From forum user reports and my limited testing I believe that with x265 the difference in efficiency between 8 and 10 bit is not very significant, it is with x264 where you get a big improvement. However, 10 bit is still better and hardware decoding is much more common for 10 bit HEVC so it is also reasonably practical, unlike 10 bit AVC or 12 bit HEVC. I always encode to 10 bit HEVC, when I encode to HEVC, with 8 or 10 bit sources.

[BobbyBoberton]

Originally Posted by Asmodian

This is not a good way to figure out this relation. You do not actually get the same quality with the same settings when you change the bitdepth. You are comparing files with different quality and different sizes, which makes it very hard to learn anything.

Ideally you would use a two pass encode while testing so the files were the same size and you can judge them on quality. To do this you also need to compress enough that you can judge differences in quality.

From forum user reports and my limited testing I believe that with x265 the difference in efficiency between 8 and 10 bit is not very significant, it is with x264 where you get a big improvement. However, 10 bit is still better and hardware 10 bit decoding is much more common for 10 bit HEVC so it is also reasonably piratical, unlike 10 bit AVC or 12 bit HEVC. I always encode to 10 bit HEVC, when I encode to HEVC, with 8 or 10 bit sources.

Ok, I can do that but I don't really understand why. I do not do video processing professionally so my knowledge is in the early-mid home enthusiast-level (I am starting to understand colorspaces and HDR metadata and stuff like that but the best way to test a video's quality to another isn't something I can easily answer besides if it looks good to you that's all that matters if it's for your personal use only obviously) so it is not obvious to me why encoding a file via CRF with only changing aq-mode=3 to hevc-aq=1 is not a valid method of comparison if you are using the same source file, shouldn't the encoder pull out as much quality (information) from the input either way? I know that making a CBR encode usually can help show you which parts of a video require the most bitrate to show the proper detail but if you are interested in getting the 'most for your money', money being time and actual electricity and you are not planning on showing this on a network with limited bandwidth (like broadcast TV) then I was told that CRF is the way to go.

Can you explain more? or point me to a resource that would help explain why?

[Asmodian]

Because as soon as you change any settings you end up with different average bitrates or file sizes.

With different size files how do you judge the results? If one file is larger it might look only a little bit better, so the setting is equivalent to lowering CRF a tiny bit (performance becomes the deciding factor). It might instead look a lot better and the setting improves quality even if a slightly higher CRF was used (a good setting, it could be worth lower performance). It could be worse too, increasing both the size and quality but making the encode less efficient, decreasing the CRF value slightly would have produced better quality at the same size. It is really hard to judge if the quality improved enough compared to the bitrate increase to be able to separate these. The same is true with a smaller file, is it simply slightly worse quality? The option might make the encode less efficient while also lowering the size, so is worse then simply raising CRF slightly.

The only situation you can judge with any accuracy would be if the larger file was worse quality. The only accurate way is to compare quality at the same average bitrate.

As an aside, be careful of judging still frames too. Good quality comparison is actually really hard. I can end up focusing on one aspect and tuning to improve that while missing some other aspect getting worse at the same time. I then come back in a few years and feel like an idiot, all that time figuring out the perfect settings and in total they were probably slightly worse than the preset would have been. Especially when I had less experiance but it is still really easy to do. I use more aggressive compression and two pass encoding when testing settings and then run high bitrate CRF encodes after I have them figured out.

[-QfG-]

I Only known 2 different HDR10 metadatas.

BT2020 and P3D65

If you will reencode a HEVC 10-Bit HDR Stream, use following custom strings for x265:

Check in MediaInfo this entry:

Mastering display color primaries : BT.2020

BT2020:

--hdr --output-depth 10 --hdr-opt --max-cll "1000,400" --master-display "G(8500,39850)B(6550,2300)R(35400,14600)WP(15635,16450)L(10000000,1)"

P3D65:

--hdr --output-depth 10 --hdr-opt --max-cll "1000,400" --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)"

You must change the blue and green entries, use the entries you see in MediaInfo of the Stream/file.

The above examples looks so in MediaInfo:

Mastering display luminance : min: 0.0001 cd/m2, max: 1000 cd/m2
Maximum Content Light Level : 1000 cd/m2
Maximum Frame-Average Light Level : 400 cd/m2

Another thing is, you must use a 10-Bit pipeline! You see it in the encoder Window on the top, there must stand: i420p10!.
I use LSMash for my DNxHR Intermediates, for HEVC Input in Mkv Container i use DGIndesNV or LWLibAv.

I'm using for Encoding StaxRip as Gui and x265 as Encoder. It's faster as FFMPEG.

[LeXXuz]

Originally Posted by -QfG-

Maximum Content Light Level : 1000 cd/m2
Maximum Frame-Average Light Level : 400 cd/m2

What do I do when these values are missing in the source video metadata?

F.e. in the source video I have here for testing purposes, I only have these values:

Video
Format                                   : HEVC
Format/Info                              : High Efficiency Video Coding
Format-Profil                            : Main 10@L5.1@High
HDR_Format/String                        : SMPTE ST 2086, HDR10 compatible
Breite                                   : 3 840 Pixel
Höhe                                     : 2 160 Pixel
Bildseitenverhältnis                     : 16:9
Bildwiederholungsrate                    : 23,976 (24000/1001) FPS
ColorSpace                               : YUV
ChromaSubsampling/String                 : 4:2:0 (Type 2)
BitDepth/String                          : 10 bits
verwendete Encoder-Bibliothek            : ATEME Titan File 3.7.8 (4.7.8.0)
colour_range                             : Limited
colour_primaries                         : BT.2020
transfer_characteristics                 : PQ
matrix_coefficients                      : BT.2020 non-constant
MasteringDisplay_ColorPrimaries          : Display P3
MasteringDisplay_Luminance               : min: 0.0000 cd/m2, max: 1000 cd/m2

I assume "Display P3" is the P3D65 you mentioned?

[Boulder]

I've always set --max-cll "0,0" if that one is missing. It seems to be quite common that it is.

[benwaggoner]

Originally Posted by Boulder

I've always set --max-cll "0,0" if that one is missing. It seems to be quite common that it is.

It is definitely better to use undefined values than incorrect values!

[LeXXuz]

Originally Posted by benwaggoner

It is definitely better to use undefined values than incorrect values!

So best would be to not set max-cll at all?

Also I noticed this line:

ChromaSubsampling/String                 : 4:2:0 (Type 2)

What does "type 2" mean? My transcoded sample just has the usual 4:2:0 string.

EDIT: Never mind, I found the explanation to that type 2 subsampling.

[Boulder]

Originally Posted by benwaggoner

It is definitely better to use undefined values than incorrect values!

I believe "0,0" is safer than NULL.

"The first value is the max content light level (or 0 if no maximum is indicated), the second value is the maximum picture average light level (or 0)."