How to convert Resolve Rec.2020 output to HEVC HDR HDR10

Hello,

I have some videos that I color graded from S-LOG3 to the Rec.2020 timeline color space and ST.2084 output color space.

I would like to output this video in some format that Davinci Resolve supports (maybe EXR or TIFF), then use some other software to transcode it to 10-bit HEVC (h.265) with the correct HDR10 flags/metadata. THe goal is to successfully play it back on an HDR10 capable TV from a USB thumb drive.

Does anybody know how to do this?

Thanks!

Not easy at all, but possible.

Check this:

http://forum.doom9.org/showthread.php?t=172724

Thanks for replying. I have been going over that thread but it's a bit difficult to follow. Is there a particular encoder and command line parameter combination that just works? I have access to Windows and Linux machines.

In that thread post #1767349 is the closest to describing how to achieve this.

I will give that a try but I am surprised there isn't a simpler way to do this.

ffmpeg.exe -nostats -i "input.mov" -strict -1 -vf scale=out_color_matrix=bt2020:out_h_chr_pos=0:out_v_chr_pos=0,format=yuv420p10 -f yuv4mpegpipe - |
x265_10bit.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"
pause

muxer.exe -i output.hevc?[fps=25] -o output.mp4
mp4box.exe -add output.mp4 -brand isom -new output_final.mp4
del output.mp4
ren output_final.mp4 output.mp4
pause

You have not much choice- x265, either itself or in ffmpeg.

This takes RGB based input MOV file- originally guy used Cineform, reads it with ffmpeg, converts to 10bit YUV 4:2:0 data and pipes to x265 encoder, which outputs elementary h265 stream. You have to then mux it into m2ts, mp4 etc. with e.g. TsMuxer or MP4Box (or ffmpeg).

ffmpeg.exe -nostats -i "input.mov" -strict -1 -vf scale=out_color_matrix=bt2020:out_h_chr_pos=0:out_v_chr_pos=0,format=yuv420p10 -f yuv4mpegpipe - |
x265_10bit.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"


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

this is your metadata bit. I don't know how to calculate these numbers, except 1000,400 which are I think max and average luma values (precisely: maximum content light level and maximum frame average light level)


If you want to use EXR sequence than you change to: -i "test_%06d.exr" (assuming your sequence starts with 1 and uses 6 digit padding: test_000001.exr, test_000002.exr....).

Many Sony, LG etc sample files don't have this metadata at all. It's still a bit of grey area

You can post 1 sec of 10bit RGB MOV sample and I will encode it.


update:

These number are for D65P3 1000-nits.

Example for D65P3 1000-nits:
+ Example for a P3D65 1000-nits monitor, where G(x=0.264, 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)


based on x265 developers info:

https://mailman.videolan.org/pipermail/ ... 10020.html

Thank you for your help! I am very happy to report that it worked.

My Resolve project is set to 29.97 fps. On the Deliver tab I exported to format EXF and Codec RGB Half (No Compression), as suggested here: http://vanhurkman.com/wordpress/?p=3548

Here is what I did:

Downloaded Windows 64-bit ffmpeg from https://ffmpeg.zeranoe.com/builds/
Downloaded latest Windows 64-bit x265 for 10-bit video from https://builds.x265.eu/ (see Latest Builds at the top)

My first filename looks like this: Untitled00199958.exr (Untitled, followed by 8 numbers and the extension exr). Since the starting number is high I need to specify it exactly in the command line with -start_number 199958, otherwise ffmpeg will complain with this error: "Could find no file with path 'Untitled%08d.exr' and index in the range 0-4" (more about this problem: http://superuser.com/questions/666860/c ... s-as-input)

Here is the command line I used to output hevc:

C:\ToolsLib\ffmpeg-20160726\bin\ffmpeg.exe -nostats -framerate 29.97 -start_number 199958 -i "C:\VideoEditing\EXR\Untitled%08d.exr" -strict -1 -vf scale=out_color_matrix=bt2020:out_h_chr_pos=0:out_v_chr_pos=0,format=yuv420p10 -f yuv4mpegpipe - | C:\ToolsLib\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 "C:\VideoEditing\output.hevc"

Command line to Mux to mp4:

C:\ToolsLib\ffmpeg-20160726\bin\ffmpeg.exe -f hevc -r 29.97 -i "C:\VideoEditing\output.hevc" -c copy "C:\VideoEditing\output.mp4"

I played output.mp4 using a USB HDD on my LG OLED TV and it recognized it as HDR10 content. As expected, while grading on an SDR monitor the image was washed out, but it played beatifully in HDR on the OLED.

I need to add the audio back and I am sure I need to tweak a bunch of command line parameters, but this is great progress so far.

Do not use 29.97 as this is incorrect and may lead to sync problems.
Use -r 30000/1001, or 24000/1001 for 23.976

Export wav out of Resolve and use this:

ffmpeg -i "source.wav" -c:a aac -b:a 320K "output.aac"

Add your audio in the muxing stage:

ffmpeg -i "source.hevc" -i "source.aac" -c:v copy -c:a copy "out.mp4"

The only thing to tweak is actual encoding. Cmd uses CRF mode, which comes up with "some bitrate". CRF=13 should give rather very high quality. There is also --uhd switch which meant to make file UHD BD compatible, which is someway good as it means most TVs should be able to play it. There are tons of parameters in x265, but if file plays fine then there is no need to play with them. Lower CRF will give better quality, but at some point it may be to high for the decoder.

One thing which you can do is to find ffmpeg build with 10bit h265 and then just use ffmpeg:

ffmpeg -i "source.wav" -r 30000/1001 -start_number 199958 -i "C:\VideoEditing\EXR\Untitled%08d.exr" -vf scale=out_color_matrix=bt2020:out_h_chr_pos=0:out_v_chr_pos=0,format=yuv420p10 -pix_fmt yuv420p10le -c:v libx265 -x265-params "crf=13:uhd-bd=1....." -c:a aac -b:a 320K "out.mp4" (x265 parameters are : separated and whole thing in "")

This way you can have video+audio all done together into mp4 in one step.
Untitled000000 is not very workflows friendly name Always use some separator: _,-, etc.

Ok, let's try this again. Using ffmpeg in one go for the whole process did not work because it did not like -c:v libx265 -x265-params ... I got this error: "Cannot open libx265 encoder.". I think it was the parameters I was using, not the fact that libx265 was missing.

Anyway, here is what I ended up using (filenames obviously changed):

ffmpeg.exe -nostats -framerate 23.976 -start_number 86400 -i "C:\Path\Important-Project\Important-Project-%08d.exr" -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 "C:\Path\Important-Project\Important-Project.hevc"

ffmpeg.exe -i "C:\Path\Important-Project\Important-Project.wav" -c:a aac -b:a 320K "C:\Path\Important-Project\Important-Project.aac"

ffmpeg.exe -f hevc -r 23.976 -i "C:\Path\Important-Project\Important-Project.hevc" -i "C:\Path\Important-Project\A1-0001_Important-Project-00086400.aac" -bsf:a aac_adtstoasc -c:v copy -c:a copy "C:\Path\Important-Project\Important-Project.mp4"

One problem that I see is that in the last command I had to use this command line switch: -bsf:a aac_adtstoasc

If I do not use it I get this error:

[mp4 @ 0000000002c800a0] Malformed AAC bitstream detected: use the audio bitstream filter 'aac_adtstoasc' to fix it ('-bsf:a aac_adtstoasc' option with ffmpeg)
av_interleaved_write_frame(): Operation not permitted

Another problem is that there is a green vertical line to the extreme right of the video - probably around 1 pixel in width.

When I play the resulting video it sort of works, but: 1) at least on my LG 65" B6 the first time I played it the audio did not work. It only started to work the second time I played it and 2) The audio seems to cut somewhat abruptly maybe a second too early, but I don't know for sure.

Use something else for muxing, maybe mp4box. Ffmpeg is not the best for this.

Hi everyone,
I'm hoping someone can make sense of the issues that I'm having.

I'm using Linux Resolve 12.5.0 in ACES 1.0 with the a P3D60 PQ (1000 nits) ODT. I'm rendering out OpenEXRs of the sequence.

In Resolve, we're reviewing color simultaneously on the Sony X300 and the LG OLED65G6P and colors match very well.

On Mac OSX 10.9.5, this is my terminal command

Code: Select all

ffmpeg -nostats -start_number 00086400 -framerate 24000/1001  -i "/Volumes/TEST/p3d60/p3d60-%08d.exr" -strict -1 -vf scale=out_color_matrix=bt2020:out_h_chr_pos=0:out_v_chr_pos=0,format=yuv420p10 -f yuv4mpegpipe - | x265 - --y4m --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 "/Volumes/TEST/hevc/test.hevc"


I then create an MP4 with:

Code: Select all

mp4box -add test.hevc -new test.mp4


The mp4 gets copied to a thumb drive. When I play it back on the LG, the image appears darker. Oranges are almost red.

I feel there's an incorrect conversion happening, but I don't know if it's being baked in into the hevc or if it's the HDR metadata (SEI info) that is wrong.

Any insight would be much appreciated!

PS: After failing to compile x265 with Xcode, I used homebrew to compile it but it doesn't recognize the "--uhd-bd" flag. Could that be the root of the issue?

This flag is only to make stream UHD BD compatible, which shouldn't really matter.
Use ffmpeg+x265 binary through piping like described above.


Metadata is for D65 white point, not D60!
You would have to follow my link (few posts up) to x265 developers explanation how to get numbers for D60.

Based on https://books.google.co.uk/books?id=3il ... es&f=false


ACES D60 x=0.3217 y=0.3377, so it means you need to use WP(16085,16885)

Aslo D65 should be rather WP(15640,16450), as x=0.3128, not 0.3127. At least based on this linked book. Wiki says 0.3127, but I rather trust this book.

Thanks, Andrew. I switched the white point to WP(16085,16890) and the issue remains. Would the G B R values need to change as well?

I was able to compile the latest version of x265_10bit which allowed me to add the --uhd-bd but that didn't help either.

No, other values are for P3, so they should be fine.
Try removing all metadata at all.

Also- are you using the same TV picture profile as for your HDMI input during grading?

If I include ONLY the flags --master-display and --max-cll, the LG TV does not detect the content as HDR.

If I include ONLY the flags --colorprim, --transfer and --colormatrix, the LG TV does detect the content as HDR (but still too dark/orange is red).

Andrew, I was hoping the TV profile changed between inputs, but they are identical.

I also played around "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)" values, drastically changing GBR's numbers - it did not seem to affect the image in any way.

Maybe your TV does not respect these numbers. Try LG support.

Andrew, thank you for your help troubleshooting.

Half a step closer (which I didn't even realize was an issue). In an effort to speed up my testing, I was generating 1080 elements, not realizing that HDR-10 standard requires 3840x2160.

Despite it being in 1080, I believe the TV understood it as HDR, but not entirely. 1080 material had a text overlay on the top right of the screen which said "HDR". 2160p material has that same text overlay but HDR is mentioned in the MP4 "info" (along with Rec.2020 and HEVC text info).

If I play with SEI flags, nothing changes so something is still not quite right. Still testing away.

Hello all,

I am seeing exactly the same ar Jerome Raim, using the same encode command line.
Was there ever a resolution to this?

Thanks

Tom

.. and should have said that display is Samsung KS7500, using the USB stick input.

I am beginning to suspect something with the TV, as for the first ~1sec the colours are not bad then switch to more orange - almost as if the TV is changing mode (although it says HDR at the top).

I had a similar thing of the TV switching out of HDR mode after a second or so when the HDR flags were not properly set on an HDFury input.

Any ideas anyone? MediaInfo shows all the correct tagging for the file (filename obscured for reasons of confidentiality).

Thanks

Testfile_MediaInfo.png (72.33 KiB) Viewed 10071 times

Use m2ts wrapper instead of mp4 (just change final file extension in ffmpeg command).
Lower bitrate to 50Mbit. Make it CBR 50Mbit and make sure there are only 2 B frames- just find settings for this in x265 manual. It maybe actual decoding issue, not really HDR related.
This is strange- people with Samsung TVs had success with this.
Update your TV firmware.

.. and should have said that display is Samsung KS7500, using the USB stick input.

How is the Samsung calibrated?

Andrew, Marc,

Thanks for the suggestions.

M2TS makes no difference. Bit rate lower at 50Mbps makes no difference. CBR makes no difference.

Samsung TV not calibrated; but two HDMI inputs:
- Decklink 4K Extreme 12G driving one HDMI
- and nVidia 1070 driving another HDMI, with HDFruy inline forcing HDR mode.

And trying my encoding works prefectly when decoding then re-encoding the LG demo sequences, but not when using my Resolve output (which comes out too red - but another thread covers this)

Tom