Body: <p>I have a couple of questions regarding intra-frame codecs for editing purposes (in Premiere Pro).</p>
  
  <p><strong>UPDATE (01/24/20). More details of the original issue after this</strong>:</p>
  
  <p>I seem to have encountered a dead end. While transcoding I noticed that the source file was tv, bt2020nc/bt2020/smpte2084 (I mean range, space, etc.), and when trying to transcode with the command specified down below (after this UPDATE) FFmpeg didn't say anything about those settings. I started to do some test giving FFmpeg input and output commands (-color_space 1, -color_trc 16, -colorspace 9, etc), and now it started to show the correct values while transcoding (bt2020nc...).</p>
  
  <p>The command line for that test was:</p>
  
  <p><code>ffmpeg -color_range 1 -color_primaries 9 -colorspace 9 -color_trc 16 -channel_layout 63 -i input.mkv -map 0:0 -c:v dnxhd -profile:v dnxhr_444 -pix_fmt yuv444p10le -color_range 1 -color_primaries 9 -colorspace 9 -color_trc 16 -acodec pcm_s24le -ar 48000 -ac 6 -channel_layout 63 -map 0:2 -hide_banner output.mxf</code></p>
  
  <p>I read that those commands only add the flags to the container, but doesn't transcode or do anything to the stream itself. Like I said, while transcoding with that command line it said yuv444p10le (tv /bt2020nc,bt2020,smpte2084), the same as the source file, but when running FFprobe it still says yuv444p10le(bt709/unknown/unknown, progressive). The rest is fine (correct DNxHR profile, fps, resolution).</p>
  
  <p>My guess was that those commands were only adding flags that maybe FFprobe and players don't actually read or use (the videos still look very different from the original footage), so I added a command using colorspace filter for actual conversion:</p>
  
  <p><code>ffmpeg -color_range 1 -color_primaries 9 -colorspace 9 -color_trc 16 -channel_layout 63 -i input.mkv -map 0:0 -c:v dnxhd -vf format=yuv420p10le,colorspace=all=bt2020:trc=smpte2084:range=tv:primaries=bt2020:space=bt2020ncl -profile:v dnxhr_444 -pix_fmt yuv444p10le -color_range 1 -color_primaries 9 -colorspace 9 -color_trc 16 -acodec pcm_s24le -ar 48000 -ac 6 -channel_layout 63 -map 0:2 -hide_banner output.mxf</code></p>
  
  <p>With that, I couldn't make past the initial checks because it says "unsupported input transfer characteristics 16 (smpte2084). No matter what I do with the colorspace filter, the output is always the same. The same happens if I delete the "trc=smpte2084" line. Anyway, that's the only error message I'm getting now, but seems like a dead end if it's not supported. And if I don't use the colorspace filter and only the flags (-color_trc...), it transcodes without issues, but FFprobe says it's BT709 (and behaves like a BT709 video while comparing it to the original footage using VLC).</p>
  
  <p><strong>QUESTIONS:</strong> Is SMPTE2084 really unsupported? Any workaround for this? Is it really possible to have BT2020 and true HDR with DNxHR 444 10 bits in a MXF container using FFmpeg? If not, any suggestions? Already tried with Adobe Media Encoder 2020, same results, but you don't have much settings to tweak there.</p>
  
  <p>Thanks in advance.</p>
  
  <p><strong>INITIAL ISSUE:</strong></p>
  
  <p><strong>A LITTLE CONTEXT:</strong></p>
  
  <p>I ripped a HDR movie to a MP4 container some months ago, using H.264 as codec (high 10, level 5, UHD, YUV, subsampling 4:2:0). The video looks great, as it should. Now I want to edit a trailer for that movie (I edit in Adobe Premiere Pro, current version), and for fast playback I need to work with proxies or transcode the source file to an intra-frame non long GOP file and use it as the source file (hopefully as lossless as that transcoding step can be). I tried for several days to transcode the source file to DNxHR 444 10 bits (using FFmpeg and then Adobe Media Encoder), but the result was always a video with the colors messed up (sometimes very washed out, sometimes over saturated).</p>
  
  <p>FFprobe of the resulting DNxHR file said that the color space was BT709 (source file is obviously BT2020), and I don't know why. The transcoding involved upsampling since the source file is 4:2:0 and DNxHR doesn't support it, but I tried upsampling to 4:4:4 and also to 4:2:2, and both of those files looked exactly the same to me, and very different from the original footage (so, I don't think upsampling is the cause of the color issue, but maybe the apparent color space change or something wrong with the metadata). The results were the same when transcoding with Adobe Media Encoder. Anyway, I seem to have given up transcoding to DNxHR and use it as the source file, unless someone has an idea of what's causing this problem. I could have worked with the source file for exporting and DNxHR LB for proxies, but there were sync issues (between source file and proxy) that defeated all purposes while editing. Prores is out of the picture, sync issues were worse (several seconds of delay).</p>
  
  <p>For the record, the command used that didn't work as expected (color wise) is:</p>
  
  <p><code>ffmpeg -channel_layout 63 -i input.mkv -map 0:0 -c:v dnxhd -vf "scale=in_range=limited:out_range=full" -color_range 2 -profile:v dnxhr_444 -pix_fmt yuv444p10le -acodec pcm_s24le -ar 48000 -ac 6 -channel_layout 63 -map 0:2 -hide_banner output.mxf</code></p>
  
  <p>I also tried without the commands "scale=in_range=limited:out_range=full" and "-color_range 2", with same results. Always used FFmpeg latest version, and I'm working in Windows 10 Pro, latest drivers and latest Klite codec pack. Video files were compared with Mediainfo, FFprobe, and visually with VLC.</p>
  
  <p>Well, like I said, I'm giving up using DNxHR as the source file for my project (it would have been ideal since it doesn't have sync issues with the DNxHR proxies, and file size is not a problem for me). A user here at the forums suggested transcoding and use H.264 intra-frame as source file, which I didn't know was an option (I didn't know H.264 was capable of intra-frame, my bad). I'm aware that one should avoid unnecesary transcoding steps, but I can't work with a H.264 UHD HDR source file (ultra slow playback), and the sync issues with proxies, no matter the codec, make it impossible to make accurate cuts. So, bottom line, I need to find a way to fix the color issue when transcoding to DNxHR, or try with an inter-frame codec that's not DNxHR and that's capable of preserving all the HDR info (and then see if it doesn't have sync issues. I'm assuming that those may dissapear when using intra-frame for both source file and proxies).</p>
  
  <p><strong>NOTE:</strong> When importing the DNxHR 444 file to Premiere Pro and looking at the Lumetri scopes tab, you can tell that the colors are clipped at 100 nits, like a regular SDR video. So apparently the color space was really reduced to BT709, and I don't know why. The H.264 source file behaves as expected, with colors going past 100 nits.</p>
  
  <p><strong>MY QUESTIONS:</strong></p>
  
  <p>1) Is H.264 intra-frame a good format for editing with a good playback performance?</p>
  
  <p>2) If H.264 intra-frame is a good option, what would be the advantages of the DNxHR codec (or Prores) over it for editing purposes? Everybody suggests DNxHD/DNxHR or Prores as intermediate codecs, but if intra-frame H.264 has the same advantages for editing and supports HDR, what would be the reason to choose another codec like DNxHR?</p>
  
  <p>3) Any ideas on what could be the cause of the colors not transcoding correctly from the H.264 source file to the DNxHR 444 10 bits one? The command looks ok to me, but FFprobe output says the DNxHR video is BT709, while with the source file it says BT2020. Like I said, apparently there's something wrong with the transcoding process regarding metadata or color space.</p>
  
  <p>4) I haven't tried to transcode the source file to a DNxHR 444 10 bits video file, but in a MOV container. I don't know how this works internally, but maybe the color issue has something to do with the container metadata or something. I may try this if there's not another suggestion (transcoding this kind of files, as you know, takes time, so I'll wait for some ideas first).</p>
  
  <p><strong>NOTE:</strong> I tried to transcode the source file in the same way (DNxHR 444, 10 bits, etc) with Adobe Media Encoder 2020 and the result was the same, with colors messed up and FFprobe saying the video is BT709. Also tried transcoding to DNxHR HQX profile (10 bits), same result.</p>
  
  <p>Any help would be greatly appreciated.</p>
  
  <p>Thanks in advance.</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-01-24T21:47:15.993Z
Comments.Text: Just a few notes: 1) HDR as per spec needs to be 10-bit.  2) Metadata flagging, gamma/color encode/decode is a messy situation, and has been for nearly 30 years.  3) You might find this ongoing discussion on the subject helpful: https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=101253  and finally, 4) On SE, you should try to limit your questions to one question per "Question," if ya know what I mean.
Comments.UserDisplayName: Jason Conrad
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-01-24T21:51:19.520Z
Comments.Text: Oh, also, don't do your color correction using proxies.  Edit with proxies if you need to, color correct the original footage, and cache the original footage to ram and loop playback if it's important that you see the image move.  Otherwise, park the playhead.
Comments.UserDisplayName: Jason Conrad
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-01-28T11:33:11.893Z
Comments.Text: 1) Yep, I’m aware of that. None of the transcoding steps I’ve made involve going lower (or higher) than 10 bits, I’ve always stayed on that bit depth to avoid extra conversion. 2) I know, and I’m suffering from it now  3) Thanks! I’m already reading it. Not sure if it’s going to help me to troubleshoot this, but I have a lot to learn about this. 4) Sorry, my reasoning was to put all my question related to the same topic on one post, to avoid multiple posts. My bad, won’t happen again, and thanks for your reply. PS: I never color correct with proxies, I use the high quality footage for that.
Comments.UserDisplayName: Raulo1985
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-01-28T11:43:20.837Z
Comments.Text: According to what I’ve read, now I’m not even sure if it’s possible to preserve HDR data when transcoding to DNxHR. The farther I could get with FFmpeg was that it showed the correct data WHILE transcoding (bt2020nc,bt2020, etc), but either FFprobe still showed bt709 on the resulting file, or stopped and showed an error message saying smpte2084 is unsupported. Apparently all the HDR important metadata info is only preserved when transcoding to codecs like h.264, but not DNxHR. And the video doesn’t look like HDR at all. I guess I’ll just have to give up, I can’t seem to find a way to fix this
Comments.UserDisplayName: Raulo1985
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-01-28T18:15:20.290Z
Comments.Text: Have you tried H.265 HEVC?  I've seen people say they'll go prores out of Resolve, then use AME to transcode to HEVC, and it handles the flagging correctly.  It's been a while since I messed with it.
Comments.UserDisplayName: Jason Conrad
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-01-28T19:57:50.293Z
Comments.Text: You mean editing with a non long-GOP format and exporting to HEVC? Yep, same results. The problem has never been the final export, but preserving colors while transcoding from source file to an intermediate codec like DNxHR. Summary of the situation: Proxies with DNxHR or Prores have sync issues if the source file is the original H.264 (that way I can’t edit properly). Only way I’ve found to avoid sync issues so far: DNxHR for both source file and proxies. And neither preserve the HDR data. So exporting to HEVC still doesn’t look as HDR because the source file isn’t HDR either.
Comments.UserDisplayName: Raulo1985
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-01-28T19:59:58.747Z
Comments.Text: And if you meant transcoding the H.264 original file to HEVC and then use the latter as source file (and DNxHR for proxies), I get the same sync issues than with the H.264 one.
Comments.UserDisplayName: Raulo1985
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-02-06T21:25:15.720Z
Comments.Text: Sorry, missed the bit about sync issues earlier.  I tried to untangle the HDR mess two or three years ago, gave it about a year, then gave up, so my information is probably out of date.  The metadata flagging wasn't supported properly by any of the major NLE's (not sure anybody *actually* has it right now)  You had to use FFMPeg or Handbrake.  In the end, there were so few combinations on the downstream end which would interpret the HDR flags correctly, that it wasn't worth the headache for me.  I.E., (TV/PC/Phone/MediaPlayer) + software/browser combination + streaming service.
Comments.UserDisplayName: Jason Conrad
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-02-06T21:43:15.553Z
Comments.Text: But I've never heard anybody have issues with proxy sync like that.  To deliver HDR right, you need big hardware, big money, a RAID, good playback on 10-bit source material (minimum for HDR delivery; companies like Netflix require higher original media bit depth), and at least a 1000 nit reference monitor.  If you're getting several seconds of delay with prores, you need faster hardware to do whatever you're trying to do.  If you can't get the expensive hardware, then you have to lower your expectations.  U don't need to edit or color in 4K to deliver it; chances are your viewer is <100% anywy
Comments.UserDisplayName: Jason Conrad
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-02-06T21:47:02.550Z
Comments.Text: Speaking of netflix... have you seen their delivery guidelines?  You might find them helpful.  https://partnerhelp.netflixstudios.com/hc/en-us/articles/215148917-Full-Technical-Specification-v9-0
Comments.UserDisplayName: Jason Conrad
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-02-06T21:48:47.767Z
Comments.Text: They also have a link to JES extensifier, which, as I understand might also help diagnose (fix?) your gamma issues if you're trying to deliver using quicktime containers (or if your DI containers are quicktime), but I think it only worked on pre-catalina Macs.  IDK about other platforms.
Comments.UserDisplayName: Jason Conrad
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-02-06T22:06:51.790Z
Comments.Text: After looking into JES extensifier, I can't endorse it.   It's a mystery to me why Netflix does.  The developer doesn't support it well, distributes it through dangerous download sites, and the top page of google results are about how to uninstall it.
Comments.UserDisplayName: Jason Conrad
Tags: <ffmpeg><h.264><transcoding><hdr><dnxhr>
Title: FFmpeg: DNxHR 444 10 bits transcoding issue (HDR project). SMPTE2084 unsupported?
UserDisplayName: Raulo1985
ThreadText: # FFmpeg: DNxHR 444 10 bits transcoding issue (HDR project). SMPTE2084 unsupported?
  
  (Asked by: username_0 on 2020-01-23)
  
  I have a couple of questions regarding intra-frame codecs for editing purposes (in Premiere Pro).
  
  **UPDATE (01/24/20). More details of the original issue after this**:
  
  I seem to have encountered a dead end. While transcoding I noticed that the source file was tv, bt2020nc/bt2020/smpte2084 (I mean range, space, etc.), and when trying to transcode with the command specified down below (after this UPDATE) FFmpeg didn't say anything about those settings. I started to do some test giving FFmpeg input and output commands (-color\_space 1, -color\_trc 16, -colorspace 9, etc), and now it started to show the correct values while transcoding (bt2020nc...).
  
  The command line for that test was:
  
  `ffmpeg -color_range 1 -color_primaries 9 -colorspace 9 -color_trc 16 -channel_layout 63 -i input.mkv -map 0:0 -c:v dnxhd -profile:v dnxhr_444 -pix_fmt yuv444p10le -color_range 1 -color_primaries 9 -colorspace 9 -color_trc 16 -acodec pcm_s24le -ar 48000 -ac 6 -channel_layout 63 -map 0:2 -hide_banner output.mxf`
  
  I read that those commands only add the flags to the container, but doesn't transcode or do anything to the stream itself. Like I said, while transcoding with that command line it said yuv444p10le (tv /bt2020nc,bt2020,smpte2084), the same as the source file, but when running FFprobe it still says yuv444p10le(bt709/unknown/unknown, progressive). The rest is fine (correct DNxHR profile, fps, resolution).
  
  My guess was that those commands were only adding flags that maybe FFprobe and players don't actually read or use (the videos still look very different from the original footage), so I added a command using colorspace filter for actual conversion:
  
  `ffmpeg -color_range 1 -color_primaries 9 -colorspace 9 -color_trc 16 -channel_layout 63 -i input.mkv -map 0:0 -c:v dnxhd -vf format=yuv420p10le,colorspace=all=bt2020:trc=smpte2084:range=tv:primaries=bt2020:space=bt2020ncl -profile:v dnxhr_444 -pix_fmt yuv444p10le -color_range 1 -color_primaries 9 -colorspace 9 -color_trc 16 -acodec pcm_s24le -ar 48000 -ac 6 -channel_layout 63 -map 0:2 -hide_banner output.mxf`
  
  With that, I couldn't make past the initial checks because it says "unsupported input transfer characteristics 16 (smpte2084). No matter what I do with the colorspace filter, the output is always the same. The same happens if I delete the "trc=smpte2084" line. Anyway, that's the only error message I'm getting now, but seems like a dead end if it's not supported. And if I don't use the colorspace filter and only the flags (-color\_trc...), it transcodes without issues, but FFprobe says it's BT709 (and behaves like a BT709 video while comparing it to the original footage using VLC).
  
  **QUESTIONS:** Is SMPTE2084 really unsupported? Any workaround for this? Is it really possible to have BT2020 and true HDR with DNxHR 444 10 bits in a MXF container using FFmpeg? If not, any suggestions? Already tried with Adobe Media Encoder 2020, same results, but you don't have much settings to tweak there.
  
  Thanks in advance.
  
  **INITIAL ISSUE:**
  
  **A LITTLE CONTEXT:**
  
  I ripped a HDR movie to a MP4 container some months ago, using H.264 as codec (high 10, level 5, UHD, YUV, subsampling 4:2:0). The video looks great, as it should. Now I want to edit a trailer for that movie (I edit in Adobe Premiere Pro, current version), and for fast playback I need to work with proxies or transcode the source file to an intra-frame non long GOP file and use it as the source file (hopefully as lossless as that transcoding step can be). I tried for several days to transcode the source file to DNxHR 444 10 bits (using FFmpeg and then Adobe Media Encoder), but the result was always a video with the colors messed up (sometimes very washed out, sometimes over saturated).
  
  FFprobe of the resulting DNxHR file said that the color space was BT709 (source file is obviously BT2020), and I don't know why. The transcoding involved upsampling since the source file is 4:2:0 and DNxHR doesn't support it, but I tried upsampling to 4:4:4 and also to 4:2:2, and both of those files looked exactly the same to me, and very different from the original footage (so, I don't think upsampling is the cause of the color issue, but maybe the apparent color space change or something wrong with the metadata). The results were the same when transcoding with Adobe Media Encoder. Anyway, I seem to have given up transcoding to DNxHR and use it as the source file, unless someone has an idea of what's causing this problem. I could have worked with the source file for exporting and DNxHR LB for proxies, but there were sync issues (between source file and proxy) that defeated all purposes while editing. Prores is out of the picture, sync issues were worse (several seconds of delay).
  
  For the record, the command used that didn't work as expected (color wise) is:
  
  `ffmpeg -channel_layout 63 -i input.mkv -map 0:0 -c:v dnxhd -vf "scale=in_range=limited:out_range=full" -color_range 2 -profile:v dnxhr_444 -pix_fmt yuv444p10le -acodec pcm_s24le -ar 48000 -ac 6 -channel_layout 63 -map 0:2 -hide_banner output.mxf`
  
  I also tried without the commands "scale=in\_range=limited:out\_range=full" and "-color\_range 2", with same results. Always used FFmpeg latest version, and I'm working in Windows 10 Pro, latest drivers and latest Klite codec pack. Video files were compared with Mediainfo, FFprobe, and visually with VLC.
  
  Well, like I said, I'm giving up using DNxHR as the source file for my project (it would have been ideal since it doesn't have sync issues with the DNxHR proxies, and file size is not a problem for me). A user here at the forums suggested transcoding and use H.264 intra-frame as source file, which I didn't know was an option (I didn't know H.264 was capable of intra-frame, my bad). I'm aware that one should avoid unnecesary transcoding steps, but I can't work with a H.264 UHD HDR source file (ultra slow playback), and the sync issues with proxies, no matter the codec, make it impossible to make accurate cuts. So, bottom line, I need to find a way to fix the color issue when transcoding to DNxHR, or try with an inter-frame codec that's not DNxHR and that's capable of preserving all the HDR info (and then see if it doesn't have sync issues. I'm assuming that those may dissapear when using intra-frame for both source file and proxies).
  
  **NOTE:** When importing the DNxHR 444 file to Premiere Pro and looking at the Lumetri scopes tab, you can tell that the colors are clipped at 100 nits, like a regular SDR video. So apparently the color space was really reduced to BT709, and I don't know why. The H.264 source file behaves as expected, with colors going past 100 nits.
  
  **MY QUESTIONS:**
  
  1) Is H.264 intra-frame a good format for editing with a good playback performance?
  
  2) If H.264 intra-frame is a good option, what would be the advantages of the DNxHR codec (or Prores) over it for editing purposes? Everybody suggests DNxHD/DNxHR or Prores as intermediate codecs, but if intra-frame H.264 has the same advantages for editing and supports HDR, what would be the reason to choose another codec like DNxHR?
  
  3) Any ideas on what could be the cause of the colors not transcoding correctly from the H.264 source file to the DNxHR 444 10 bits one? The command looks ok to me, but FFprobe output says the DNxHR video is BT709, while with the source file it says BT2020. Like I said, apparently there's something wrong with the transcoding process regarding metadata or color space.
  
  4) I haven't tried to transcode the source file to a DNxHR 444 10 bits video file, but in a MOV container. I don't know how this works internally, but maybe the color issue has something to do with the container metadata or something. I may try this if there's not another suggestion (transcoding this kind of files, as you know, takes time, so I'll wait for some ideas first).
  
  **NOTE:** I tried to transcode the source file in the same way (DNxHR 444, 10 bits, etc) with Adobe Media Encoder 2020 and the result was the same, with colors messed up and FFprobe saying the video is BT709. Also tried transcoding to DNxHR HQX profile (10 bits), same result.
  
  Any help would be greatly appreciated.
  
  Thanks in advance.
  
  **Tags:** ffmpeg, h.264, transcoding, hdr, dnxhr
  
  > **Comments:**
  > **username_1**: Just a few notes: 1) HDR as per spec needs to be 10-bit.  2) Metadata flagging, gamma/color encode/decode is a messy situation, and has been for nearly 30 years.  3) You might find this ongoing discussion on the subject helpful: https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=101253  and finally, 4) On SE, you should try to limit your questions to one question per "Question," if ya know what I mean.  
  > **username_1**: Oh, also, don't do your color correction using proxies.  Edit with proxies if you need to, color correct the original footage, and cache the original footage to ram and loop playback if it's important that you see the image move.  Otherwise, park the playhead.  
  > **username_0**: 1) Yep, I’m aware of that. None of the transcoding steps I’ve made involve going lower (or higher) than 10 bits, I’ve always stayed on that bit depth to avoid extra conversion. 2) I know, and I’m suffering from it now  3) Thanks! I’m already reading it. Not sure if it’s going to help me to troubleshoot this, but I have a lot to learn about this. 4) Sorry, my reasoning was to put all my question related to the same topic on one post, to avoid multiple posts. My bad, won’t happen again, and thanks for your reply. PS: I never color correct with proxies, I use the high quality footage for that.  
  > **username_0**: According to what I’ve read, now I’m not even sure if it’s possible to preserve HDR data when transcoding to DNxHR. The farther I could get with FFmpeg was that it showed the correct data WHILE transcoding (bt2020nc,bt2020, etc), but either FFprobe still showed bt709 on the resulting file, or stopped and showed an error message saying smpte2084 is unsupported. Apparently all the HDR important metadata info is only preserved when transcoding to codecs like h.264, but not DNxHR. And the video doesn’t look like HDR at all. I guess I’ll just have to give up, I can’t seem to find a way to fix this  
  > **username_1**: Have you tried H.265 HEVC?  I've seen people say they'll go prores out of Resolve, then use AME to transcode to HEVC, and it handles the flagging correctly.  It's been a while since I messed with it.  
  > **username_0**: You mean editing with a non long-GOP format and exporting to HEVC? Yep, same results. The problem has never been the final export, but preserving colors while transcoding from source file to an intermediate codec like DNxHR. Summary of the situation: Proxies with DNxHR or Prores have sync issues if the source file is the original H.264 (that way I can’t edit properly). Only way I’ve found to avoid sync issues so far: DNxHR for both source file and proxies. And neither preserve the HDR data. So exporting to HEVC still doesn’t look as HDR because the source file isn’t HDR either.  
  > **username_0**: And if you meant transcoding the H.264 original file to HEVC and then use the latter as source file (and DNxHR for proxies), I get the same sync issues than with the H.264 one.  
  > **username_1**: Sorry, missed the bit about sync issues earlier.  I tried to untangle the HDR mess two or three years ago, gave it about a year, then gave up, so my information is probably out of date.  The metadata flagging wasn't supported properly by any of the major NLE's (not sure anybody *actually* has it right now)  You had to use FFMPeg or Handbrake.  In the end, there were so few combinations on the downstream end which would interpret the HDR flags correctly, that it wasn't worth the headache for me.  I.E., (TV/PC/Phone/MediaPlayer) + software/browser combination + streaming service.  
  > **username_1**: But I've never heard anybody have issues with proxy sync like that.  To deliver HDR right, you need big hardware, big money, a RAID, good playback on 10-bit source material (minimum for HDR delivery; companies like Netflix require higher original media bit depth), and at least a 1000 nit reference monitor.  If you're getting several seconds of delay with prores, you need faster hardware to do whatever you're trying to do.  If you can't get the expensive hardware, then you have to lower your expectations.  U don't need to edit or color in 4K to deliver it; chances are your viewer is <100% anywy  
  > **username_1**: Speaking of netflix... have you seen their delivery guidelines?  You might find them helpful.  https://partnerhelp.netflixstudios.com/hc/en-us/articles/215148917-Full-Technical-Specification-v9-0  
  > **username_1**: They also have a link to JES extensifier, which, as I understand might also help diagnose (fix?) your gamma issues if you're trying to deliver using quicktime containers (or if your DI containers are quicktime), but I think it only worked on pre-catalina Macs.  IDK about other platforms.  
  > **username_1**: After looking into JES extensifier, I can't endorse it.   It's a mystery to me why Netflix does.  The developer doesn't support it well, distributes it through dangerous download sites, and the top page of google results are about how to uninstall it.  
  
  ---
  
  ## 0 answers
  
  