Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > High Efficiency Video Coding (HEVC)

Reply
 
Thread Tools Search this Thread Display Modes
Old 26th June 2020, 03:27   #1  |  Link
BobbyBoberton
Registered User
 
Join Date: Jul 2018
Posts: 24
Is there a simple way to conserve HDR10 through adobe/handbrake?

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:

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:

Code:
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

Last edited by BobbyBoberton; 29th June 2020 at 06:45.
BobbyBoberton is offline   Reply With Quote
Old 26th June 2020, 19:12   #2  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,389
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?
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 1st July 2020, 09:14   #3  |  Link
excellentswordfight
Lost my old account :(
 
Join Date: Jul 2017
Posts: 153
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.

Quote:
--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.

Last edited by excellentswordfight; 1st July 2020 at 09:33.
excellentswordfight is offline   Reply With Quote
Old 1st July 2020, 17:54   #4  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,389
Quote:
Originally Posted by excellentswordfight View Post
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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 2nd July 2020, 01:22   #5  |  Link
BobbyBoberton
Registered User
 
Join Date: Jul 2018
Posts: 24
Quote:
Originally Posted by excellentswordfight View Post
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,
Quote:
(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 is offline   Reply With Quote
Old 3rd July 2020, 07:40   #6  |  Link
BobbyBoberton
Registered User
 
Join Date: Jul 2018
Posts: 24
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:

Quote:
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:

Quote:
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

Last edited by BobbyBoberton; 3rd July 2020 at 08:04. Reason: release my other post please
BobbyBoberton is offline   Reply With Quote
Old 5th July 2020, 03:50   #7  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,745
-pix_fmt yuv420p10le is the key
Blue_MiSfit is offline   Reply With Quote
Old 7th July 2020, 21:34   #8  |  Link
BobbyBoberton
Registered User
 
Join Date: Jul 2018
Posts: 24
Quote:
Originally Posted by Blue_MiSfit View Post
-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.
BobbyBoberton is offline   Reply With Quote
Old 8th July 2020, 22:15   #9  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,389
Quote:
Originally Posted by BobbyBoberton View Post
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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 9th July 2020, 01:06   #10  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,012
Quote:
Originally Posted by BobbyBoberton View Post
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?
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 11th July 2020, 23:49   #11  |  Link
BobbyBoberton
Registered User
 
Join Date: Jul 2018
Posts: 24
Quote:
Originally Posted by nevcairiel View Post
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

Last edited by BobbyBoberton; 12th July 2020 at 00:46. Reason: clarity
BobbyBoberton is offline   Reply With Quote
Old 12th July 2020, 01:08   #12  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 3,992
Quote:
Originally Posted by BobbyBoberton View Post
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.
__________________
madVR options explained

Last edited by Asmodian; 12th July 2020 at 06:47.
Asmodian is offline   Reply With Quote
Old 12th July 2020, 01:23   #13  |  Link
BobbyBoberton
Registered User
 
Join Date: Jul 2018
Posts: 24
Quote:
Originally Posted by Asmodian View Post
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?

BobbyBoberton is offline   Reply With Quote
Old 12th July 2020, 06:38   #14  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 3,992
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.
__________________
madVR options explained

Last edited by Asmodian; 12th July 2020 at 07:00.
Asmodian is offline   Reply With Quote
Old 12th July 2020, 12:42   #15  |  Link
-QfG-
QfG Group Germany
 
-QfG-'s Avatar
 
Join Date: Oct 2018
Location: Germany
Posts: 60
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:

Quote:
Mastering display color primaries : BT.2020
BT2020:
Quote:
--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:
Quote:
--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:

Quote:
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.
__________________
AMD Ryzen 9 3950x / Gigabyte Aorus Master X570 / 32 GB G.Skill F4 3200C16-16GVK / ASUS STRIX GeForce GTX1070 8GB GDDR5

Last edited by -QfG-; 12th July 2020 at 12:53.
-QfG- is offline   Reply With Quote
Old 14th July 2020, 13:13   #16  |  Link
LeXXuz
17 years and counting...
 
LeXXuz's Avatar
 
Join Date: Oct 2002
Location: Germany
Posts: 303
Quote:
Originally Posted by -QfG- View Post
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:
Code:
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?
LeXXuz is offline   Reply With Quote
Old 14th July 2020, 14:58   #17  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,934
I've always set --max-cll "0,0" if that one is missing. It seems to be quite common that it is.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 14th July 2020, 17:27   #18  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,389
Quote:
Originally Posted by Boulder View Post
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!
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 14th July 2020, 18:50   #19  |  Link
LeXXuz
17 years and counting...
 
LeXXuz's Avatar
 
Join Date: Oct 2002
Location: Germany
Posts: 303
Quote:
Originally Posted by benwaggoner View Post
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:
Code:
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.

Last edited by LeXXuz; 14th July 2020 at 20:27.
LeXXuz is offline   Reply With Quote
Old 15th July 2020, 08:49   #20  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,934
Quote:
Originally Posted by benwaggoner View Post
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)."
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Reply

Tags
conservation, ffmpeg, hdr, hevc, metadata

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 01:00.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.