YouTube - DaVinci Resolve - HDR Initiative

YouTube Blog:

Starting today, any creator can upload HDR videos to YouTube. You can learn more about uploading HDR videos here. To make sure creators can tell awesome stories with even more color, we’ve been working with companies across the industry. We’ve worked with the DaVinci Resolve team to make uploading HDR just as simple as SDR videos to YouTube. We’ve also outfitted the YouTube Spaces in LA and NYC with all the gear needed to produce great HDR content.

Forbes Article

YouTube is keen to stress in its blog post, though, that any creator can now upload HDR videos. The streaming platform has been working with a variety of companies – including the DaVinci Resolve team – to make the process of uploading HDR as straightforward as possible, and has already fitted its YouTube Spaces in Los Angeles and New York with everything required to create HDR content.

I am trying to figure out how to output and upload my HDR videos from Davinci Resolve Studio + maybe some external encoders like ffmpeg.

Will post here if I figure it out.

Here is the documentation from YouTube on this subject so far:
https://youtube.googleblog.com/2016/11/ ... r-hdr.html
https://support.google.com/youtube/answer/7126552
https://support.google.com/youtube/answer/1722171

4k/UHD H.265 files with HDR metadata get rejected by YouTube, that is the first thing I tried since I output my videos that way usually.

The documentation at https://support.google.com/youtube/answer/7126552 mentions you can output video with Davinci Resolve but it only supports partial metadata in the files. I am trying to figure this out too since they are vague about it.

What I tried so far (Windowx x64):

H.265 MP4 with HDR metadata - does not work, YouTube refuses to even process the video

H.264 MP4 - severe banding and does not recognize it as HDR so it looks washed out (I guess Davinci Resolve does not set the metadata)

QuickTime DNxHR HQX MOV - terrible green artifacts, video washed out (so not recognized as HDR). QuickTime on my own machine shows the same thing, so I guess this one's on Resolve.

The YouTube documentation mentions you can output H.264 MP4 and then use their tool to add the HDR metadata: https://github.com/YouTubeHDR/hdr_metadata

However, they did not upload the Windows version (mkvmerge.exe) yet, but I opened up an Issue in Github: https://github.com/YouTubeHDR/hdr_metadata/issues/1

I refuse to participate until YouTube can actually handle Rec709. You gotta walk before you can run.

So I found mkvmerge.exe since it's part of MKVToolNix. But I am not sure how the YouTube version of this is supposed to be different.

I ran mkvmerge on an H.264 (8 bit?) HDR video exported from Davinci Resolve using this command line:

mkvmerge.exe ^
-o ProjectOutput.mkv ^
--colour-matrix 0:9 ^
--colour-range 0:1 ^
--colour-transfer-characteristics 0:16 ^
--colour-primaries 0:9 ^
--max-content-light 0:1000 ^
--max-frame-light 0:300 ^
--max-luminance 0:1000 ^
--min-luminance 0:0.01 ^
--chromaticity-coordinates 0:0.68,0.32,0.265,0.690,0.15,0.06 ^
--white-colour-coordinates 0:0.3127,0.3290 ^
ProjectInput.mov

Then I uploaded the .mov file. As far as I can tell YouTube still does not recognize this as HDR (their HDR to SDR conversion does not trigger and the video looks washed out).

It's strange that YouTube does not recognize the video as HDR as even the mkvinfo.exe taken from the YouTube repo shows it as such:

+ EBML head
|+ EBML version: 1
|+ EBML read version: 1
|+ EBML maximum ID length: 4
|+ EBML maximum size length: 8
|+ Doc type: matroska
|+ Doc type version: 4
|+ Doc type read version: 2
+ Segment, size 598170044
|+ Seek head (subentries will be skipped)
|+ EbmlVoid (size: 4027)
|+ Segment information
| + Timecode scale: 1000000
| + Muxing application: libebml v1.3.4 + libmatroska v1.4.5
| + Writing application: mkvmerge v9.5.0 ('Quiet Fire') 64bit
| + Duration: 29.113s (00:00:29.113)
| + Date: Tue Nov 08 05:46:45 2016 UTC
| + Segment UID: 0xa3 0xc4 0xa6 0x3f 0x56 0x44 0x25 0xed 0x82 0xd5 0x98 0xd7 0xa3 0xa7 0x46 0x94
|+ Segment tracks
| + A track
| + Track number: 1 (track ID for mkvmerge & mkvextract: 0)
| + Track UID: 11399832362612848259
| + Track type: video
| + Lacing flag: 0
| + MinCache: 1
| + Codec ID: V_MPEG4/ISO/AVC
| + CodecPrivate, length 39 (h.264 profile: Main @L5.1)
| + Default duration: 41.708ms (23.976 frames/fields per second for a video track)
| + Language: und
| + Video track
| + Pixel width: 3840
| + Pixel height: 2160
| + Display width: 3840
| + Display height: 2160
| + Video colour information
| + Colour matrix: 9
| + Colour range: 1
| + Colour transfer: 16
| + Colour primaries: 9
| + Max content light: 1000
| + Max frame light: 300
| + Video colour mastering metadata
| + Red colour coordinate x: 0.68
| + Red colour coordinate y: 0.32
| + Green colour coordinate x: 0.265
| + Green colour coordinate y: 0.69
| + Blue colour coordinate x: 0.15
| + Blue colour coordinate y: 0.06
| + White colour coordinate x: 0.3127
| + White colour coordinate y: 0.329
| + Max luminance: 1000
| + Min luminance: 0.01
|+ EbmlVoid (size: 1060)
|+ Cluster

I suspect Resolve only outputs 8-bit H.264, while YouTube documentation says they only support 10 bit. So instead I will again try to export DNxHR HQX and run mkvmerge on it.

Nope, the DNxHR HQX mkv file still yield a bunch of green artifacts and weird colors when uploaded to YouTube which I still think are because of Resolve.

I am running out of options here

Maybe somebody with a Mac can try ProRes?

[Peter Chamberlain]

You don't say what version of Resolve you are on... I'm told QT container with ProRes or DNx works.. for you try other DNx flavours. Hard to believe YouTube would list DaVinci Resolve if it didn't work....

Have you reviewed here?
https://support.google.com/youtube/answer/7126552

There are constant issues with DNxHR from Resolve. Seen few times that companies have to keep patching their software to handle DNxHR from Resolve. Sounds like something is quite not up to standard.

I suspect Resolve only outputs 8-bit H.264, while YouTube documentation says they only support 10 bit. So instead I will again try to export DNxHR HQX and run mkvmerge on it.

DNxHR in MKV container is something wild, but youtube says they support it.
Whole youtube guide regarding HDR is one big mess

Start with HDR video exported as "normal" h264, ProRes or DNxHR (mov or mp4), use their tool to insert HDR metadata and upload final .mkv file to youtube.

They don't support h265 which is actually the only format which can properly store all HDR metadata (inside codec data not container) in headers according to the defined spec. Youtube's mkv approach is a bit of hack and their "own" way to pass HDR metadata. None of the other containers or codecs support it per defined spec, but it can be done in MOV, same way as it was done in mkv. It's just not in MOV spec and don't think it will ever be added in official way. It can be done on a basis that companies agree on same consistent naming, so all software can understand it. MOV headers can store tons of metadata- e.g. Arri/Sony stores a lot of metadata, but only some tools have been updated to to read it.

very interesting to read about Davinci Resolve and HDR :
http://www.mysterybox.us/blog/2016/10/2 ... vering-hdr

next :

How to Upload HDR Video to YouTube (with a LUT)
http://www.mysterybox.us/blog

It would be more interesting if Resolve could add all HDR metadata to MOV headers (not just Rec.2020 flagging), even if this is at the moment would be only supported on import by Resolve itself.
Why do we have to so often to "jump" to open source tools? It's quite intriguing that open source tools drive things as much as pro applications (if not more in some cases).

So for youtube in order to recognise stream as HDR it's enough to have Rec.2020 flagging. This is bare minimum and fairly easy to do in MOV container (flagging in h264 codec itself will probably also work). In order to provide detailed HDR matadata to youtube MKV container is the only way.

Not long time ago Resolve use to not add even standard Rec.709 flagging in MOV

[Dwaine Maggart]

Related to QuickTime DNxHR HQX files created with current Resolve on Windows: There is an issue with the current NVIDIA drivers that cause the green banding across the top of the image, if you are using Pascal NVIDIA cards.

The 375.63 and 375.70 driver have this issue.

Would recommend using the 372.70 or 373.06 driver for now, if you see this HQX issue.

Dwaine, thank you so much for letting me know. I indeed have a lot of issues with the newer NVIDIA drivers (artifacts in videos and GIFs). I will downgrade and try again.

Peter, I am using Resolve 12.5.3 on Windows 10 64 bit. Yes I am following the documentation.

Dwaine, thank you so much for letting me know. I indeed have a lot of issues with the newer NVIDIA drivers (artifacts in videos and GIFs). I will downgrade and try again.

Peter, I am using Resolve 12.5.3 on Windows 10 64 bit. Yes I am following the documentation.

Those artefacting with the 375.70 driver have been acknowledged by nVidia, and the hotfix version 375.76 has been released.

Piotr

I'm talking about import DNxHR files made in Resolve into other apps. Looks like companies have problems with DNxHR files from Resolve.

Please,

With this desire to promote Davinci Resolve and its lead in HDR editing, future version 12.5.4 should integrate all the tools and "flags" that from the Delivery tab, the final clip will be uploaded directly to YouTube directly without having to go through "external" tools (new preset to rule out errors?) and of course including all broadcasters (my tV for example ) and not only for the PRORES (thank you in advance for those that are under Windows. Thanks).

Exactly, what about this initiative:
youtube and BM talk to each other, agree on custom metadata in MOV container (same what youtube does in MKV), so people can simply upload HDR masters out f Resolve. That's what I would call a real initiative and this is what this industry is lacking quite often (in most cases each company do its own things). In many cases it's very surprising how not much needs to be done (together) to make a huge difference.

I hope (I think) we are going to good intentions with the professionalism of Blackmagic Design!
OUPS... I'm not mistaken?

youtube and BM talk to each other, agree on custom metadata in MOV container (same what youtube does in MKV), so people can simply upload HDR masters out f Resolve.

This is precisely what needs to be done. And doing so will undoubtedly cause a large number of content creators to migrate from their current NLE/Color solution -- to Resolve. This is a win-win -- with Blackmagic gaining more market share, inviting more customers into the overall BMD ecosystem, and selling more I/O products.

And the funnies part that it's easy to do.

Well, partial success. I downgraded the NVIDIA drivers, exported as DNxHR HQX, ran mkvmerge, then uploaded the video to YouTube.

Using a Chromecast Ultra my OLED TV switches to HDR and displays the video.

However, there are a few problems:
- For some reason I have a lot of trouble getting the Ultra to show a good quality version of the video stream. From my PC I can view the stream in 4K just fine, but Ultra has issues with it, even on a wired 100/100 network.
- The HDR to SDR conversion YouTube uses is pretty poor, so when viewing the video on an SDR screen it looks .. shall we say inferior. I have to get started on a custom LUT that gets better results. Let's pray I don't have to do this separately per video
- The (SDR) YouTube Android mobile phone app is freaking out when trying to play the video. It worked once then any subsequent plays (even after restarting the app completely) yields just an error message: "There was a problem while playing. Tap to retry."
- I am not entirely convinced what I see on the TV is what I graded. The colors seem just a bit off (not a huge problem, but maybe I am picky). Will investigate more.

For SDR probably it's best to upload your own LUT to youtube.

The struggle continues. So now I can correctly output and upload 4K HDR video to YouTube but I ran into a couple of other bugs:

P0: Framerate bug in HDR to SDR video stream conversion - https://github.com/YouTubeHDR/hdr_metadata/issues/2

P1: Chromecast Ultra often and inconsistently decides to use HD stream instead of 4K - https://github.com/YouTubeHDR/hdr_metadata/issues/3

The first issue only appears when playing HDR video on an SDR screen.

But the second issue unfortunately affects 4K HDR videos + Chromecast Ultra.

I also have a third issue where the YouTube video manager does not tell you if it recognized a video as HDR, but I guess I can live with that.

Let's hope for some quick fixes. To be honest the lack of HEVC support, the hacky command line tools to add HDR metadata, and the general flakiness is very disappointing. YouTube had HDR demos at CES in January, what on Earth have they been doing since then to support content producers?

Also a potentially useful tidbit: based on my experiments I think (but not sure) that the HDR to SDR conversion that YouTube performs automatically is very similar to the "HDR 1000 nits to Gamma 2.4.cube" LUT that comes with Resolve.

It would be good if the YouTube video manager could confirm when I upload a LUT if they actually use it, but alas they do not even tell me if the video I uploaded is HDR. I have to acutally play it with the Chromecast Ultra and let the TV tell me.

YouTube today resolved the first issue I was having with the missing mkvmerge.exe from their repo. They uploaded the file and closed the bug. https://github.com/YouTubeHDR/hdr_metadata/issues/1

YouTube confirmed the framerate bug I found in the HDR to SDR conversion.

"Thanks for reporting the bug. We will take care of it ASAP."

https://github.com/YouTubeHDR/hdr_metadata/issues/2

(Sigh.. and I also found an HDR related bug in Premiere Pro that they also confirmed. The pains of being an early adopter...)

Related to QuickTime DNxHR HQX files created with current Resolve on Windows: There is an issue with the current NVIDIA drivers that cause the green banding across the top of the image, if you are using Pascal NVIDIA cards.

The 375.63 and 375.70 driver have this issue.

Would recommend using the 372.70 or 373.06 driver for now, if you see this HQX issue.

Hey Dwaine,
There is a new driver for Nvidia out today. 375.86
Any thoughts on if/when you'll know it's safe? Or am I going to be a guinea pig for this?

[Dwaine Maggart]

It appears that the problem is NOT fixed in the 375.86 driver.

It appears that the problem is NOT fixed in the 375.86 driver.

Problem still NOT fixed in the 376.33 driver too.