Which format for HDR10 deliverables?

Forgotten about handbrake- easier to use and does have custom commands parser, but no 10bit.

handbrake is not used in StaxRip. You have to read from page 5 and later.
I will test. It is experimental but NVencC / H265 and NVIDIA 1070/1080 it will (should) go fast.

Did not say that. You are talking about something totally different- hardware h265 encoding.

then you can try:

-c:v libx264 -preset fast -g 50 -b:v 100M -x264-params bframes=3:vbv-bufsize=150000:vbv-maxrate=150000:colorprim=bt2020:transfer=bt2020-10:colormatrix=bt2020nc -c:a aac -b:a 320K

This may give answer what triggers HDR mode.

Andrew

The above definitely doesn't trigger HDR mode, as expected... BUT, it does play through MP-HC

Piotr

C:\ffmpeg -i "path to source file" -pix_fmt yuv420p10le -c:v libx265 -preset fast -g 50 -b:v 100M -x265-params bframes=3:vbv-bufsize=150000:vbv-maxrate=150000:colorprim=bt2020:transfer=smpte-st-2084:colormatrix=bt2020nc:masterdisplay="G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)":max-cll="1000,400" -c:a aac -b:a 320K "path to output.mp4"

Source and output have to have extensions. Numbers are for D65P3 1000-nits max.

This does play as HDR, but the picture isn't bright enough (super-brights are lower than in my source Resolve project). Probably I should use DCI-P3 and 1500 nits as the max. How to code this exactly? The DCI-P3 is 0.680 0.320 0.265 0.690 0.150 0.060 0.3127 0.3290 - how to "translate" it?

Do you think your TV needs masterdisplay info?
I think some read this flag, others don't.

To answer that, I need to play with DCI-3P and max brightness, so please answer my questions above (for a super-fast training course in ffmpeg )

Piotr

Already translated, but ffmepg does not support masterdisplay option, so it's not getting into final mp4.

You need to use ffmpeg+x265 as a separate binary and then mux to mp4 separately. This is what I tried to avoid.

then you can try:

-c:v libx264 -preset fast -g 50 -b:v 100M -x264-params bframes=3:vbv-bufsize=150000:vbv-maxrate=150000:colorprim=bt2020:transfer=bt2020-10:colormatrix=bt2020nc -c:a aac -b:a 320K

This may give answer what triggers HDR mode.

Andrew

The above definitely doesn't trigger HDR mode, as expected... BUT, it does play through MP-HC

Piotr

So h264 definitely won't trigger HDR.

You said that rec202-10 for transfer did?

Please try:
colorprim=bt709:transfer=bt709:colormatrix=bt709

and

colorprim=bt709:transfer=smpte-st-2084:colormatrix=bt2020nc

Looks like setting Rec.2020 is the trigger for HDR mode( +codec has to be h265).

found : http://x265.readthedocs.io/en/default/cli.html


--master-display <string>

SMPTE ST 2086 mastering display color volume SEI info, specified as a string which is parsed when the stream header SEI are emitted. The string format is “G(%hu,%hu)B(%hu,%hu)R(%hu,%hu)WP(%hu,%hu)L(%u,%u)” where %hu are unsigned 16bit integers and %u are unsigned 32bit integers. The SEI includes X,Y display primaries for RGB channels and white point (WP) in units of 0.00002 and max,min luminance (L) values in units of 0.0001 candela per meter square. (HDR)

Example for a P3D65 1000-nits monitor, where G(x=0.265, y=0.690), B(x=0.150, y=0.060), R(x=0.680, y=0.320), WP(x=0.3127, y=0.3290), L(max=1000, min=0.0001):

G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)

Note that this string value will need to be escaped or quoted to protect against shell expansion on many platforms. No default.

--max-cll <string>

Maximum content light level (MaxCLL) and maximum frame average light level (MaxFALL) as required by the Consumer Electronics Association 861.3 specification.

Specified as a string which is parsed when the stream header SEI are emitted. The string format is “%hu,%hu” where %hu are unsigned 16bit integers. 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). (HDR)

Example for MaxCLL=1000 candela per square meter, MaxFALL=400 candela per square meter:

–max-cll ?1000,400?

Note that this string value will need to be escaped or quoted to protect against shell expansion on many platforms. No default.

and many others..

This info is in the command but x265 inside ffmpeg does not support it.
You need x265 binaries itself which do preserve masterdisplay command properly.

So h264 definitely won't trigger HDR.

Definitely not.

You said that rec202-10 for transfer did?

With h.265 it did, but colors were less faithful than with 2084.

Please try:
colorprim=bt709:transfer=bt709:colormatrix=bt709

and

colorprim=bt709:transfer=smpte-st-2084:colormatrix=bt2020nc

You mean to try the above with h.265? Just making sure...

Piotr

OK, so - as expected:

colorprim=bt709:transfer=bt709:colormatrix=bt709 - didn't trigger HDR
colorprim=bt709:transfer=smpte-st-2084:colormatrix=bt2020nc - did trigger HDR



PS. In those glorious LG and Sony clips, I saw both primaries and matrix being 2020.

Yes, to find out what triggers HDR mode in TV.

This info is in the command but x265 inside ffmpeg does not support it.
You need x265 binaries itself which do preserve masterdisplay command properly.

this is not what I read in https://trac.ffmpeg.org/wiki/Encode/H.265

"Generally, options are Passed with the x265 to -x265-params argument. Fine-tuning For the encoding process, you can pass The Therefore Any Option That Is listed in the documentation x265. Keep in mind That fine-tuning'any of the options Generally is not Necessary, UNLESS you absolutely know what you need to change. "

and the link references http://x265.readthedocs.io/en/default/

I may be wrong version of ffmpeg. Bye

Yes, to find out what triggers HDR mode in TV.

My answers in the previous post, edited.

I also used this syntax with separate x265 exec:

ffmpeg.exe -nostats -i "25p.mxf" -strict -1 -vf scale=out_color_matrix=bt2020:out_h_chr_pos=0:out_v_chr_pos=0,format=yuv420p10 -f yuv4mpegpipe - | x265-64bit-10bit-latest.exe - --y4m --uhd-bd --crf 13 --tune grain --colorprim bt2020 --transfer smpte-st-2084 --colormatrix bt2020nc --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)" --max-cll "1000,400" --output "25p.hevc"

then:

ffmpeg-20160726\bin\ffmpeg.exe -f hevc -r 25.00 -i "25p.hevc" -c copy "25p.mp4"

The output does NOT trigger HDR!

Piotr

Found reason.
There is a typo- it should be master-display and then it works fine.
For the future- don't copy someones commands, do it yourself

Yes, to find out what triggers HDR mode in TV.

My answers in the previous post, edited.

I also used this syntax with separate x265 exec:

ffmpeg.exe -nostats -i "25p.mxf" -strict -1 -vf scale=out_color_matrix=bt2020:out_h_chr_pos=0:out_v_chr_pos=0,format=yuv420p10 -f yuv4mpegpipe - | x265-64bit-10bit-latest.exe - --y4m --uhd-bd --crf 13 --tune grain --colorprim bt2020 --transfer smpte-st-2084 --colormatrix bt2020nc --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)" --max-cll "1000,400" --output "25p.hevc"

then:

ffmpeg-20160726\bin\ffmpeg.exe -f hevc -r 25.00 -i "25p.hevc" -c copy "25p.mp4"

The output does NOT trigger HDR!

Piotr

You don't have to. Just correct command to master-display (not masterdisplay) and you can use just ffmpeg.
It maybe the separate muxing or maybe master display info.

If adding master display doesn't trigger HDR then that is strange

Try pure ffmepg way with fixed command and adjust max-cll to 1500 if this is what you had in Resolve (not sure about minimum value).

Try this:

colorprim=bt709:transfer=smpte-st-2084:colormatrix=bt709

if this doesn't trigger then it's color matrix header.

You can also try

colorprim=bt2020:transfer=smpte-st-2084:colormatrix=bt709

just to have all possibilities covered.

OK, I will try all the combinations - currently waiting for Resolve to finish exporting some longer clip, in different format this time (but hopefully retaining my HDR metadata).

In the meantime, on the side note:

When I use the casting functionality, how does it really work? Is it DNLA? I mentione Youtube before, because - when a cast clip completes playback - my TV is left on the Youtube channel screen...

Also, speaking of Youtube: I can play 4K demo clips from there fluently using YT channel of my Samsung, but when I try to play those same clips on my PC (from youtube.com website) my download speed is too low to play them... How does it work? How on earth can my Samsung not even choke once?

Thanks

Piotr

Not sure. Casting is just sending data to TV over network, so TV plays original file (not your PC)- that's why HDR works (same as playing from USB).

Because TV is hooked up over ethernet cable no wi-fi(?), because your machine wi-fi has issues(?) Connect your PC over cable to router and see if this helps.

You can install some DLNA sever on PC and than can access files on PC from TV menu. Few possible options...
I owed suggest to plug TV over cable to the router, so things are more solid.

OK, I will try all the combinations - currently waiting for Resolve to finish exporting some longer clip, in different format this time (but hopefully retaining my HDR metadata).

Piotr

Format doesn't matter much, just stay with YUV based one, so ffmpeg doesn't have to do RGB<->YUV conversion. Cineform 10bit YUV will work well also. DNxHR is not fully supported yet in ffmpeg- there were some issues with specific modes.

OK, thanks.

One more thing please explain Andrew:

- using your proposed syntax (no separate x265 exec), I'm getting 8bit h.265 files. With the syntax I posted above (with "| x265-64bit-10bit-latest.exe "), I got 10bit clips - but they didn't trigger HDR!

Questions:

1. how to get the best of both, i.e. HDR-triggering 10bit h.265 files?
2. you mentioned my DCI-P3 primaries "have already been translated" - where? You said your syntax was for D65...

I realize I'm just sucking precious knowledge out of you, but if you answer this question you will really have helped me with a good kick-start Thanks!

Piotr

PS. As to my TVV and PC Internet connection, it actually is the other way around currently: TV is on wi-fi, PC- on Ethernet cable... I really don't get how the Samsung can read clips from Youtube that quick!

1. Are your using ffmpeg from my link? I bet you not, but one from their website which is not build with 10bit x265.
2. master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)" these are P3 coordinates and D65 white point, just multipled by some number.

I think I found one answer in ffmpeg output:

"Incompatible pixel format 'yuv420p10le' for codec 'libx265', auto-selecting format 'yuv420p'"

- so it probably pick 8 bit here. How to change it so it gets 10 bits?

1. Are your using ffmpeg from my link? I bet you not, but one from their website which is not build with 10bit x265.
2. master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)" these are P3 coordinates and D65 white point, just multipled by some number.

We cross-posted. I'm usign this:
ffmpeg -i "50pYUV.avi" -pix_fmt yuv420p10le -c:v libx265 -preset fast -g 50 -b:v 100M -x265-params bframes=3:vbv-bufsize=150000:vbv-maxrate=150000:colorprim=bt2020:transfer=smpte-st-2084:colormatrix=bt2020nc:master-display="G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)":max-cll="1000,400" -c:a aac -b:a 320K "50pYUV.mp4"


Isn't it yours? Perhaps different ffmpeg version...

Just finished rendering - strange, because using the exact syntax I quoted above, I didn't get HDR clip

It was from Cineform YUV this time; previously from DNxHR444, and that worked as HDR (only in 8bits)... What do you make of it?

Piotr

I gave your link to ffmpeg with x265 10bit build, so use this one ( zaranoe ones are compiled with 8bit x265).

Cineform, DNxHD or 10bit uncompressed is irrelevant here.

Use correct ffmepg so you get 10bit and then try with master-display and without. This is the only difference.

Mine is the newest build:

ffmpeg version N-82092-g89ec4ad Copyright (c) 2000-2016 the FFmpeg developers
built with gcc 5.4.0 (GCC)

encoder : Lavc57.63.103 libx265

And still getting:

- HDR files (8bit though) only from DNxHR444 Resolve exports (which are 12bit 444)
- non HDR from anything else (tried Uncompressed YUV 10bit 422 and some others)


???

PS. Doesn't it sound the bell? Myself debating with Walter, over only caching to "DNxHR HDR" (which is 444, 12 bit)" or "Uncompressed 16bit (half-float) HDR", in order to retain that HDR?

It doesn't as you fully transcode file, so source is totally irrelevant for final output (at least for headers). ffmepg makes headers and they don't really depend on the input, but on command which you use. Your working file was probably done with command which had wrong option for master display.

It's not good. As I said- compiled with 8bit x265, so there is no way to make final h265 files 10bit.

Source files is not your problem, but most likely master-display option. You are again adding many variables at the same time, which only complicate things.

Use ffmpeg from my link and try without mater-display option:

-pix_fmt yuv420p10le -c:v libx265 -preset fast -g 50 -b:v 100M -x265-params bframes=3:vbv-bufsize=150000:vbv-maxrate=150000:colorprim=bt2020:transfer=smpte-st-2084:colormatrix=bt2020nc -c:a aac -b:a 320K

then try with full command including master display+max-cll
Make sure you are using correct command with proper options, mainly regarding primaries, transfer and color matrix. You should also stick to one testing method at the moment and the best is over USB.

It doesn't as you fully transcode file, so source is totally irrelevant for final output (at least for headers). ffmepg makes headers and they don't really depend on the input, but on command which you use. Your working file was probably done with command which had wrong option for master display.

It's not good. As I said- compiled with 8bit x265, so there is no way to make final h265 files 10bit.

Source files is not your problem, but most likely master-display option. You are again adding many variables at the same time, which only complicates things.

Use ffmpeg from my link and try without mater-display option:

-pix_fmt yuv420p10le -c:v libx265 -preset fast -g 50 -b:v 100M -x265-params bframes=3:vbv-bufsize=150000:vbv-maxrate=150000:colorprim=bt2020:transfer=smpte-st-2084:colormatrix=bt2020nc -c:a aac -b:a 320K

then try with full command including master display+max-cll
Make sure you are using correct command with proper options, mainly regarding primaries, transfer and color matrix.

Sorry, but the input matters. I did 2 renders with the above syntax (no master-display):

- my DNxHR444 files render to HDR (although in 8bit only)
- my other formats do NOT render to HDR...

Piotr

I gave your link to ffmpeg with x265 10bit build, so use this one ( zaranoe ones are compiled with 8bit x265).

Cineform, DNxHD or 10bit uncompressed is irrelevant here.

Use correct ffmepg so you get 10bit and then try with master-display and without. This is the only difference.

Can you please give me an ffmpeg compilation download link with 10-bit x265 then?

Please

Piotr

It doesn't as you fully transcode file, so source is totally irrelevant for final output (at least for headers). ffmepg makes headers and they don't really depend on the input, but on command which you use. Your working file was probably done with command which had wrong option for master display.

It's not good. As I said- compiled with 8bit x265, so there is no way to make final h265 files 10bit.

Source files is not your problem, but most likely master-display option. You are again adding many variables at the same time, which only complicates things.

Use ffmpeg from my link and try without mater-display option:

-pix_fmt yuv420p10le -c:v libx265 -preset fast -g 50 -b:v 100M -x265-params bframes=3:vbv-bufsize=150000:vbv-maxrate=150000:colorprim=bt2020:transfer=smpte-st-2084:colormatrix=bt2020nc -c:a aac -b:a 320K

then try with full command including master display+max-cll
Make sure you are using correct command with proper options, mainly regarding primaries, transfer and color matrix.

Sorry, but the input matters. I did 2 renders with the above syntax (no master-display):

- my DNxHR444 files render to HDR (although in 8bit only)
- my other formats do NOT render to HDR...

Piotr

Check them with latest mediainfo and I bet you they won't have exactly the same headers.
Are you 100% sure command was the same and ffmpeg version was the same?

What do you mean by not render to HDR?
Forget about HDR flagging or anything like this as Resolve doesn't do it.
All what you need to do is to pass YUV based data to ffmepg, so it can take it as is.
Does your rendered master look the same for Cineform, DNxHD, v210 in MPC/QT player? It should look about the same (forget if it's correct look or not). This is only thing which ffmpeg cares- to get some YUV data and convert to other format. If data is already YUV then it won't mess with it.

I gave your link to ffmpeg with x265 10bit build, so use this one ( zaranoe ones are compiled with 8bit x265).

Cineform, DNxHD or 10bit uncompressed is irrelevant here.

Use correct ffmepg so you get 10bit and then try with master-display and without. This is the only difference.

Can you please give me an ffmpeg compilation download link with 10-bit x265 then?

Please

Piotr

Already gave it to you in first post regarding command.

https://sourceforge.net/projects/ffmpeg ... p/download

but you not follow, which makes simple things very convoluted.

Thanks - I must have missed that link. Sorry - this whole lot of information is new to me, I never used ffmpeg before. Will try your syntax with the right version of ffmpeg/x265 and report...

Thanks,

Piotr

Use 5 sec test file, so you don't waste time.
Once all is fine then you can play with your amazing clips

OK, no I understand why you were so doubtful about using DNxHR - this ffmpeg build doesn't support it at all.

Also, what do you make of this warning from x265:
Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead.

Piotr

EDIT: my DNxHR files don't work, and still no HDR from Uncompressed YUV! I'm getting exactly the same info as from your very first test clip: Audio not supported. And no HDR

OK, no I understand why you were so doubtful about using DNxHR - this ffmpeg build doesn't support it at all.

Also, what do you make of this warning from x265:
Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead.

Piotr

EDIT: my DNxHR files don't work, and still no HDR from Uncompressed YUV! I'm getting exactly the same info as from your very first test clip: Audio not supported. And no HDR

You can ignore this warning.

Add some audio to the source file, even if it's silence and try with and without master-display option.

Looks like most Samsumg demo clips are done with this info:

Color primaries : BT.2020
Transfer characteristics : SMPTE ST 2084
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312700 y=0.329000
Mastering display luminance : min: 0.0500 cd/m2, max: 1000.0000 cd/m2


which translates to this for x265 command:

colorprim=bt2020:transfer=smpte-st-2084:colormatrix=bt2020nc:master-display="G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,500)"

My file has audio, and it worked like a charm with the other ffmpeg build, but:

- only with DNxHR 444 files
- due to 8bit x265, output h.265 files were 8 bit

So I guess I must return to that other ffmpeg build, but change the syntax to use 10-bit x265.exe (I downloaded this executable: x265-64bit-10bit-latest.exe). I used this:

ffmpeg.exe -nostats -i "25p.mxf" -strict -1 -vf scale=out_color_matrix=bt2020:out_h_chr_pos=0:out_v_chr_pos=0,format=yuv420p10 -f yuv4mpegpipe - | x265-64bit-10bit-latest.exe - --y4m --uhd-bd --crf 13 --tune grain --colorprim bt2020 --transfer smpte-st-2084 --colormatrix bt2020nc --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)" --max-cll "1000,400" --output "25p.hevc"

ffmpeg-20160726\bin\ffmpeg.exe -f hevc -r 25.00 -i "25p.hevc" -c copy "25p.mp4"

- but the result didn't trigger HDR, either (even from DNxHR444 file the "25p.nxf" is).

May I kindly ask you for help in doing that? TIA

Piotr

PS. Funnily enough, the only successful renders so far have been those with your syntax, but using "my" ffmpeg build (with 8bit x265), and only with DNxHR444 files...

I asked you for apples you brought oranges.
I may leave you now- you have plenty info to play with.
One more thing- you should try .ts (transport stream) as this is what Samsung is using for all their clips.
Files may also have to by UHD not HD!

Oh, give me a break with this patronizing tone - will you?

We're ALL trying to learn here - including yourself, my all-knowing BesserWisser Friend.

I hoped you would give me a kick-start - but you would continue patronizing. So be it, I'm 62 year s old and learnt so many things in my life that learning the ffmpeg syntax will be just one more thing.

Thank you for your cooperation so far; I hope you learned something too,

Piotr

Not much at all... still don't know what triggers HDR mode. Other bits are already known.
And whatever you say I know that source file is totally irrelevant here when it comes to triggering HDR mode by transcoded file.

I told you what triggers HDR mode, but - just like Walter in the similar dispute, only related to caching - you won't listen to a novice like me. The output from Resolve must be what they call "HDR format" in their cache format nomenclature - and on Windows, it can only be one of the 2 formats:

- Uncompressed: 16bit hlalf-float
- DNxHR HQX HDR (or 444 on export)...

Also, I told you that since "your" ffmpeg build doesn't accept DNxHR at all, and "mine" - only has 8bit x265, the following must be done:

- "your" ffmpeg build may be used with your syntax, but ONLY on a 12bit, 444 Uncompressed file from Resolve
or
- "my" ffmpeg build with my DNxHR 444 files, but with syntax calling explicitly the 10-bit x265.

I also asked you kindly and politely to help me build such a syntax, but you preferred to patronize me in your answer. Cheers

Piotr

We are talking about export, not cache. Your cache options can be whatever works for you. When you finish work, you export your master. Do you see any HDR specific export options? Is Resolve limited to any specific export format when project is HDR?
Anything can carry your final data (even compressed h264) as these are just some pixels with some brightness value. Data as any other. This data starts make special sense when TV knows that this is HDR video. If it doesn't know it's HDR it still displays it, same way as any file will cary it (it may be destroyed a bit due to be e.g. compressed or not be 10bit, but this is not the point).

If Resolve is "different" and requires a special format for HDR data on export than that's a different story (I asked you if Cineform or DNxHR or uncompressed look the same in some player- I assume it does). This is still totally irrelevant for your test with final mp4 files. Whatever your file has HDR data or not it's headers in final mp4 which trigger HDR mode not actual video data. Your source master is totally irrelevant here- it can be just 1 second of black video. If it's not HDR video then it will just look wrong in HDR mode. Simple as this.

It's not my build but someone else- it's older build but with 10bit x265, so DNxHR won't work, which is irrelevant as DNxHR plays no role here at all when it comes to triggering HDR mode in TV.

Where is the answer for: what setting/which header in final mp4 triggers HDR mode? With your chaotic testing approach it's impossible to establish. According to you it's DNxHR source file which is total nonsense

You have to understand that data inside video file is one thing and how this data is described in headers is another. They should be aligned, but can be also totally messed up, that's why all pro software allows to overwrite interpretation and manual set e.g. color space, aspect etc.

There is no standard for signalling HDR (even P3 color space) in MOV, MXF container, neither in private headers of ProRes, DNxHR etc. so these files cary no useful info for automatic decision. Only h265 can carry such a info in a standardised manner. In all other cases you simply just know that this file is HDR. For ffmepg fact that source is DNxHR or v210 or Cineform makes not much difference- it takes decoded YUV data, converts to 4:2:0 and encodes to h265. That's why it's better to use YUV based format, as you almost have no chances to destroy your original data. In case of RGB based format ffmpg has to do RGB->YUV conversion (which involves color matrix etc ) and things can go wrong as your DNxHR, Cineform etc files will be most likely tagged as Rec.709.

Instead do following simple testing approach you jump and change 5 things at the same time. Since you have seen it working it means it can be done with your TV. Other reports (different TVs) suggest less issues than you have- it rather works.
Possible variables:
- x265 version (should not really matter as long as there is no bug in a specific version and it's fairly recent one)
- UHD v HD frame size- not verified
- color primaries, transfer... setting- established as bt2020+smpte-st-2048+bt2020nc
- mp4 v. ts container- not fully verified, should rather not matter
- 8bit v. 10bit- not fully verified
- x264 v. x265- almost sure it needs to be x265

File needs to be played over USB (or streamed to TV), but yet again 1 method should be used for start and most likely USB way. Quite simple.

For HDMI you can inject the metadata required for HDR with an HDFury Integral.

Yes, or wait until madVR author does it, so it costs you nothing
Nice box, useful in some places.

I told you what triggers HDR mode, but - just like Walter in the similar dispute, only related to caching - you won't listen to a novice like me. The output from Resolve must be what they call "HDR format" in their cache format nomenclature - and on Windows, it can only be one of the 2 formats:

- Uncompressed: 16bit hlalf-float
- DNxHR HQX HDR (or 444 on export)...

Piotr

So when you export it as e.g. 10bit uncompressed and open this file in MPC than your original HDR data (watched on normal monitor) is not good (altered somehow by exporter)? Have you looked at DNxHR versus other formats exports from HDR projects in MPC or QT player? Are non-DNxHR altered somehow by exporter? It would make not much sense.
Caching format which preserves all data is important and maybe handled specially, but all exports should give the same result as much as each format allows for it (compressed v uncompressed, 8bit v 10bit).

OK, theory aside - could you just try to explain why I was able to get HDR-triggering h.265 clips from both DNxHR and/or Uncompressed 10bit (Cineform) using your syntax and ffmpeg compilation of 2016-10-23, but NOT using the same syntax and ffmpeg compilation of 2016-07-01? OK, the later doesn't support DNxHR at all - but why not Uncompressed?

As a matter of fact, I could say I've found the solution (ffmpeg of 2016-10-23, of course) and call it the day - were it not for the fact that this compilation only includes 8-bit capable x.265, and so my HEVC files - properly reported as HDR by my TV - are 8bit only. I said I never used ffmpeg before, but for someone as experienced as you it should be easy to modify the ffmpeg / x265 syntax in such a way that the more powerful ffmpeg version (of 2016-10-23) pipes through the "x265-64bit-10bit-latest.exe" encoder... I tried using the syntax:

ffmpeg.exe -nostats -i "input.xxx" -strict -1 -vf scale=out_color_matrix=bt2020:out_h_chr_pos=0:out_v_chr_pos=0,format=yuv420p10 -f yuv4mpegpipe - | x265-64bit-10bit-latest.exe - --y4m --uhd-bd --crf 13 --tune grain --colorprim bt2020 --transfer smpte-st-2084 --colormatrix bt2020nc --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)" --max-cll "1000,400" --output "output.hevc"

ffmpeg-20160726\bin\ffmpeg.exe -f hevc -r 25.00 -i "25p.hevc" -c copy "25p.mp4"

- but it works similar to your syntax with the older ffmpeg version - i.e. the output h.265 files are 10 bit OK, but not HDR-flagged...

Piotr

There is nothing to change there- it should work (try .ts in 2nd step for transport stream muxing). I just don't like the fact that it's muxed in 2nd step, but x265 can output only elementary stream, so there is no other way. You can try mp4box for muxing instead of ffmpeg, but I would rather make it working in ffmepg as there is everything there what is needed.

All what I can guess is: user error. Different command, something was different. I can just guess, but you admitted that DNxHR has nothing to do with it as Cineform source also worked. There is NO reason why uncompressed source would not work with 100% same command+ffmpeg and same playback method. It's basically impossible.

Different compilation has different x265 code inside, so this is may be the reason for different ffmpeg versions. There are things happening deep inside h265 streams which you don't see or have control over. Maybe some incompatibility. x265 code is very alive and changing every day.

You need to compile latest ffmpeg+x265 with 10bit flag, so things are up to date as much as they can be.

Have you established other variables: UHD v HD frame size, mp4 v ts muxer, existing supported audio track?

I'm 99% sure answer is there in your tests, but I leave it for you to figure it out.

If you have these working and not working mp4 files, just compare their headers in latest mediainfo- this may give you an answer.

As you can imagine Andrew, before I engage in fine-tuning the HEVC files (by checking the influence of various parameters - including the ones you mentioned), I'd like to have the most important part of the workflow sorted out so that each encode yields a valid HDR 10-bit H.265 file...

It's just beyond my understanding how a newer ffmpeg compilation have less powerful and less up-to-date x265 inside.

Thanks for your cooperation so far,

Piotr

Exactly, so focus on it and test all possible scenarios with old and new ffmepg. You have just few few of them, so maybe 10 or so files.

Latest ffmpeg has newer and probably better/improved x265 code, not sure why you're saying it's worse?

Latest ffmpeg has newer and probably better/improved x265 code, not sure why you're saying it's worse?

Well - do you think its internal x265 encoder is capable of more than 8-bit renders? Why would many people be using the external x265-64bit-10bit-latest.exe with it (and there are separate executables for 8 and 12 bit, too)? Why does:

"-pix_fmt yuv420p10le"

default to 8-bit, while with the older ffmpeg compilation it defaults to 10 bits as intended? Do you think it's only the syntax of the above which changed? Currently, it generates the following warning message:

"Incompatible pixel format 'yuv420p10le' for codec 'libx265', auto-selecting format 'yuv420p'"

So I fund it in help that for displaying valid pixel formats, 'pix_fmts' should be used. This yields a very long list of options, where I found this:

Pixel formats:
I.... = Supported Input format for conversion
.O... = Supported Output format for conversion
..H.. = Hardware accelerated format
...P. = Paletted format
....B = Bitstream format

FLAGS NAME NB_COMPONENTS BITS_PER_PIXEL
[...lots of lines before...]
IO... yuv420p10le 3 15
[...lots of lines after...]

Now - I have no idea how this could be 15 bits per pixel! NONE of the plethora of this paramter possible values seem to yield 10 bits per pixel (and the numbers range from 8 to 64, with such odd numbers like 27 in-between). So I used:

"-pix_fmt yuv420p"

The above is supposed to yield 12 bits per pixel, but the ouput is still 8-bit and the warning is issued:

" Too many bits 6826.666667 > 6144 per frame requested, clamping to max"

This leads me to the conclusion that bith depth should be defined elsewhere in the command line... Or should the desired number be NB_COMPONENTS x 10? What do you think?



Piotr

PS. When comparing Mediainfo report on x265 used by the older ffmpeg build (the one outputting HDR flag, but only 8bit HEVC on output) with that from the newer one - I still suspect the latter's x265 is indeed limited to 8bits, which answers your question as per the quote above:

- older: Writing library: x265 1.9+226-6561d8676581:[Windows][GCC 5.3.0][64 bit] 10bit
- newer: Writing library: x265 0.0:[Windows][GCC 5.4.0][64 bit] 8bit

Which would mean no change it the yuv420pxxx pixel format parameter will help - to use the older ffmpeg build and get 10-bit HEVC, piping through the external x265-64bit-10bit-latest.exe encoder is necessary. But that produces results identical to those of the newer ffmpeg build (10-bit, but not HDR-flagged h.265 clips).

I already gave you answer for this.

You can't do anything to turn on 10bit x265 in your ffmpeg as this is set during compilation process when executable is created from the source code.
You are again focusing on wrong bit.
This is the reason why many people (compiling custom ffmpeg with 10bit x265 version is not what many can do) use piping from ffmpeg to x265 itself as those can be easily found precompiled with 10bit support.

Piping command will preserve 10bit (as long as x265 is 10bit version) and you can use any combinations of versions for ffmpeg+ x265.
Every ffmpeg version itself supports 10bit and not only. It's x265 inside ffmpeg which is the problem.

I will send you some sample which will tell you if newer version does help with anything. I have latest stable versions of ffmpeg+x265 10bit compiled, but for Mac as I don't use Pc.

OK Andrew, I guess I needed a night's sleep to look at it afresh.

We agree that to get 10bits with the newer ffmpeg compilation which does support DNxHR, piping through external x265 executable is necessary - I have just checked and all my formats (the preferrable DNxHR444 to which I cache, so export is faster from Resolve - but also Uncompressed YUV) encode properly with HDR-triggering flag. The only thing left is the audio - the syntax I found somewhere and have been using (first run to xx.hevc, then from hevc to xx.mp4) doesn't encode it the way your syntax does.

I found the way to encode audio separately and mux it - but all this is becoming cumbersome. So my kind request to you now is to help me devise a single-pass syntax piping through 10-bit x265 and encoding audio channel at one go. Possible? TIA

Piotr

Try this:

https://drive.google.com/file/d/0B5Sgcx ... sp=sharing


Using piping always requires 2 steps as you have to do muxing later. x265 outputs only elementary h265 stream. Good luck with just changing extension

You don't need piping approach to get 10bit, just custom compiled latest version of ffmpeg+x265 10bit.