Dnxhr Uhd Files turn out unreadable

I have some Uhd deliveries to make, they render fine, but when i try to open them in After effects i get the message "this mov file is damaged or unsupported". When trying to reimport in Resolve, it does not even see the file in the media page.

Maybe it has to do with my workaround: i need subtitles with transparency rendered from Resolve, which does not seem to be possible. So i added a green solid, render it with subtitles in Dnxhr, 10 bit in Resolve and key it in After Effects and render to Prores 4444 with Alpha.

I did the same with a HD project before (which worked fine) and i wonder where could be the problem, because i get this error.
I´m on Windows 10, Resolve Studio 16.2.7.010
Any ideas? here are the settings.

dnxhr.PNG (14.57 KiB) Viewed 4567 times

AE_dnxhr.PNG (4.88 KiB) Viewed 4567 times

Your hardware?

DNxHR .movs don’t play well. Blame Apple. Make them .MXFs and choose Full Range Data levels under the advanced settings. 444 10bit DNxHR has a metadata tagging bug. They should always be Full. Auto doesn’t work properly for that specific configuration


HPz840 - 2x 14 Core 2.6GHz - 64GB RAM
Windows 10 Pro 2004
2x RTX 2080Ti (SD 460.89)
Resolve Studio 16.2.7
Decklink 4K Extreme (11.6)
FSI CM250
Panasonic FZ1000
Mini Panel

Try installing the latest version of the Avid codec package.

Are those still used? I was under the impression that the QT framework is abandoned.

thanks for your input, i used dnxhr in quicktime container before, with 2048x858 scope formats, it worked fine. I got aware of the video range bug, thanks for pointing that out again, it´s a shame that it does not work as expected.

I used a technichal lut video to data range to compensate, but i should be right from the start.

I´ll report back, once i finish the render.

I think there use to be an issue with DNxHR alpha in Resolve and in Adobe as well.
Try rendering 12bit version in Resolve. Are you on latest v16?
If not try Cineform RGBA.
You can also try mentioned MXF route.
And you want to use full levels (as pointed) as Adobe is hard coded and expects 444 files to be full range.
It's not necessarily Resolve issue. Resolve properly flags range in DNxHR headers, it's just Adobe which is hard coded instead of reading this flag. I do think thought that by default 444 files should be rather exported as full range as they are RGB based.

If you do use green screen background and key in AE then what is the point of using transparency ?

Maybe it has to do with my workaround: i need subtitles with transparency rendered from Resolve, which does not seem to be possible.

Try having some active video background track (not Resolve generated) and on top subs.
If you want to export subs only with transparency, just go to video track and put opacity to 0 (do not disable it as then exporter gets disabled which sounds like a bug). Then in export use codec with alpha (actually Cineform/ProRes may be good option), in subtitles option set them to be burned-in and export.
I'm not sure if this is going to work, but may.

Are those still used? I was under the impression that the QT framework is abandoned.

I assume so, but was just a suggestion in case Adobe reverts to QT if it can't read an MOV using its internal engine.

I think there use to be an issue with DNxHR alpha in Resolve and in Adobe as well.
Try rendering 12bit version in Resolve.

TMK DNxHR 444 does not support alpha. That’s why it’s not labeled 4444
- RGBA.
A tiff, EXR or png image sequence is suggested on other forums.


HPz840 - 2x 14 Core 2.6GHz - 64GB RAM
Windows 10 Pro 2004
2x RTX 2080Ti (SD 460.89)
Resolve Studio 16.2.7
Decklink 4K Extreme (11.6)
FSI CM250
Panasonic FZ1000
Mini Panel

I think I'm messing Premiere releases with Resolve
Does Resolve support alpha in any video codec at all?

https://documents.blackmagicdesign.com/ ... c_List.pdf


HPz840 - 2x 14 Core 2.6GHz - 64GB RAM
Windows 10 Pro 2004
2x RTX 2080Ti (SD 460.89)
Resolve Studio 16.2.7
Decklink 4K Extreme (11.6)
FSI CM250
Panasonic FZ1000
Mini Panel

Ok.
How do you create file with alpha in Resolve then as it doesn't work.
If I have single video layer and move it 50% up and this already should create transparency.
When I export it then I never get file with alpha.

Same thing in Premiere works straight away and exported files import with alpha to Resolve.

Works flawlessly here in ProRes 4444, but it's a shame if there's no alternative under Windows.

So there is huge bug.
On Mac choosing codec which meant to support alpha activates an extra option called "Export Alpha" which can be ticked. If you do so exported file has alpha embedded and all works fine.

On Windows (Resolve 16.2.8) this extra option NEVER shows up, so there is about no way to export file with alpha. Only formats which work are uncompressed ARGB, BGRA formats, maybe some DPX with alpha in pixel format.

Things have improved in version 17. Might be worth looking into.

(Though I second the notion of bypassing QuickTime and using MXF just as a matter of course.)

Maybe it has to do with my workaround: i need subtitles with transparency rendered from Resolve, which does not seem to be possible.

Try having some active video background track (not Resolve generated) and on top subs.
If you want to export subs only with transparency, just go to video track and put opacity to 0 (do not disable it as then exporter gets disabled which sounds like a bug). Then in export use codec with alpha (actually Cineform/ProRes may be good option), in subtitles option set them to be burned-in and export.
I'm not sure if this is going to work, but may.

This method does work.
On Windows you have very limited choice of export formats which support alpha (eg. uncompressed RGBA), as all others which meant to do so are not working as expected.
Maybe Resolve v17 has it fixed on Windows- just look for 'Export Alpha' option in export menu.

Things have improved in version 17. Might be worth looking into.

(Though I second the notion of bypassing QuickTime and using MXF just as a matter of course.)

So all this time functionality was there but because of this bug no one was able to access it

Things have improved in version 17. Might be worth looking into.

(Though I second the notion of bypassing QuickTime and using MXF just as a matter of course.)

Alpha data and info about its presence is stored inside codec data itself, not container, so it should be irrelevant if you use MXF or MOV (although if there are extra design limitations then it can make a difference). Premiere should read both.

I think there use to be an issue with DNxHR alpha in Resolve and in Adobe as well.
Try rendering 12bit version in Resolve.

TMK DNxHR 444 does not support alpha. That’s why it’s not labeled 4444
- RGBA.
A tiff, EXR or png image sequence is suggested on other forums.

DNxHR supports Alpha on all of its variants - its biggest advantages over ProRes.

In both cases alpha channels is basically a separate data next to main video data. Some codecs support it only if main video is 444, like ProRes. Others support it regardless of the main data type.
One of the differences is that DNxHR uses uncompressed alpha (if I'm correct) and ProRes uses lossless compression, so makes it at about 2x or more smaller. In case of complex alpha channel this will make file sizes very different.

https://documents.blackmagicdesign.com/ ... c_List.pdf

I found and wanted to attach this after my last post but apparently you need to hit reply/send (and spell check) first.


HPz840 - 2x 14 Core 2.6GHz - 64GB RAM
Windows 10 Pro 2004
2x RTX 2080Ti (SD 460.89)
Resolve Studio 16.2.7
Decklink 4K Extreme (11.6)
FSI CM250
Panasonic FZ1000
Mini Panel

But you are sure that you are in Individual Clips mode when looking for the box to tick for Alpha?
It is not offered with Single Clip, neither on a Mac.

ok, i tried different things, here are my findings:

i tried dnxhr in the mxf container, i got some problems, where the rendering got stuck at 0 % which was surprising, the project was only the solid + subtitles burnt in, should be no problem and started with 33 fps per minute. (I´m rendering from a internal raid to a ssd, both with decent speed).

Next i tried exr, because of the compression. This was really sluggish, but it finished and file size was quite ok.

I then tried changing the solid for a green tiff, which brought an improvement in stability and performance.

I could not verify that you can export direct with alpha. I´ll have a look into it, once i deliver some files.

But you are sure that you are in Individual Clips mode when looking for the box to tick for Alpha?
It is not offered with Single Clip, neither on a Mac.

On Mac alpha option shows for both modes for me, so all seems to be fine.

ok, i tried different things, here are my findings:

i tried dnxhr in the mxf container, i got some problems, where the rendering got stuck at 0 % which was surprising, the project was only the solid + subtitles burnt in, should be no problem and started with 33 fps per minute. (I´m rendering from a internal raid to a ssd, both with decent speed).

Next i tried exr, because of the compression. This was really sluggish, but it finished and file size was quite ok.

I then tried changing the solid for a green tiff, which brought an improvement in stability and performance.

I could not verify that you can export direct with alpha. I´ll have a look into it, once i deliver some files.

You may have some installation/machine/drivers problems if your renders crash like this.

You need to have "Export Alpha" option visible and ticked, otherwise files will never have alpha.

You may have some installation/machine/drivers problems if your renders crash like this.

Yea i´m wondering, although i did a lot of deliveries lately, which caused no problems, i only hat trouble with the combination of solid + Subtitles.

Ok- may be Resolve bug as well

Wow, thanks Andrew, that's new in 17 (and very welcome). Still discovering some of the 300+ new features …

FYI. A colorist chat from the other day revealed that even though DNx supports alpha in all iterations, PPro only reads alpha in/from 444 encoding.
Unsure if Avid is different.


HPz840 - 2x 14 Core 2.6GHz - 64GB RAM
Windows 10 Pro 2004
2x RTX 2080Ti (SD 460.89)
Resolve Studio 16.2.7
Decklink 4K Extreme (11.6)
FSI CM250
Panasonic FZ1000
Mini Panel

You get the "export alpha" option when you select to export individual clips. I use GV (Great Valley) codec for that exact purpose of exporting subtitles with alpha to Fusion standalone (for Prores export) with success.

There are DNxHR flavors made in Resolve that Adobe doesn't like. Did a test once to determine which and published the findings here but can't remember which thread that was in. I think it was the bit depth that was the problem. Can't remember if it needs to be 10 bit or 12 bit.

Bothe mentioned limitations are not true anymore as starting with Premiere 14.6 there is a new DNxHR decoder/encoder.
12bit files are supported now and alpha works in 422 modes as well (as per AVID reference spec):

https://helpx.adobe.com/premiere-pro/us ... 21.ug.html

Good to know. Thanks for the update.


HPz840 - 2x 14 Core 2.6GHz - 64GB RAM
Windows 10 Pro 2004
2x RTX 2080Ti (SD 460.89)
Resolve Studio 16.2.7
Decklink 4K Extreme (11.6)
FSI CM250
Panasonic FZ1000
Mini Panel

So does it to work now with latest Premiere? Please share.

Sent from my Mi 9T using Tapatalk

What?
I've tried some DNxHR files with alpha and they work fine in Premiere. Tested on Mac as on PC alpha option in Resolve 16 is broken.
12bit DNxHR files also work fine now in Premiere. Only 1 thing which you need to be aware is levels. You must set levels manually to full for 444 option in Resolve if you planning to work with them in Premiere. Premiere is hard coded and expects 444 files to be full range. Resolve by default uses limited.
Another thing are 422 files out of Premiere. When you import them to Resolve you must manually set levels to video. Premiere has bug and flags them as full, when in reality data is limited (not sure if Premiere 14.9 fixed it, but I don't think so).

Unfortunately developers have issues with setting flag which can have only 2 values

No problem here with DNxHR 444 12-bit in UHD with Alpha into After Effects.