Malfunctions on DOM 2.12.4

[skiff]

Hi
A weird bug, I try to make a DCP form AVID DNxHR file (what I do very often ) but now it's looking blurry and Pixels on the preview window and also after the export- DCP.
I checked the DCP on esydcp player and DOM player it's the same picture like what I see on the preview window.

Any idea what happened???
I attached pictures.

2018-04-21 09.21.42 am.jpg

2018-04-21 09.28.08 am.jpg

2018-04-21 10.05.18 am.jpg

Best
Skiff

[Carsten]

Can you remember the last version that did it right for you? I see you are on a Mac - it is easy to have different versions installed, you may give one of the recent 2.11 or 2.10.5 a try. Are you sure it doesn't only happen for specific DNxHR files? Can you test with an 'older' file that you know used to work?



- Carsten

[skiff]

Hi Carsten,

Thank you for your response.
I downloaded the version 2.10.5 for the test and Its seems the same problem (attached picture)

I don't remember if it worked for me in the past the DNxHR.
But DNxHD works fine.
I think DNxHR is common and important codec.
DOM dose not support DNxHR?

Best,
Skiff

2018-04-21 03.10.44 pm.jpg

[Carsten]

The trouble is, DCP-o-matic needs FFMPEG framework for these codecs. Similar to ProRes in WIndows, FFMPEG codecs are not 'official' manufacturer/licensed codecs, but 're-engeineered'. And some of the more recent/exotic varieties may not have been fully developed or debugged. Carl is updating FFMPEG regularly when FFMPEG is updated, but in general, aside from some parametric optimizations, Carl can not implement these Codecs all by himself. It may be, though, that SOME DNxHR variants may work well, others not. So the question is, will DNxHR not work at all, or will only some specific varieties be supported? And if so, can you constrain your source footage to these supported parameters.

When you google 'DNxHR FFMPEG', you will quickly see some of these issues.

Maybe you can supply a short snippet of DNxHR footage to Carl (e.g. through WeTransfer) so he can have a look?

I think a while ago, someone already mentioned issues with 4k DNxHR files on this forum....? Ah, yes... https://dcpomatic.com/forum/viewtopic.p ... nxhr#p3800

- Carsten

[skiff]

Hi all,

Carsten thank you for your answer.
Finally I found a film of type DNxHR, and it works fine with DOM 2.14.4.
Maybe it’s because it is AVID DNxHR, 3840 × 2160
(attached picture)

So if I will export the DNxHR from Davinci Resolve as JPEG2000 for the DOM will it be fine?
Any ideas or tips about this?
Is it better to export ProRse in this case?

Best,
Skiff

2018-04-22 02.51.14 pm.jpg

2018-04-22 02.51.14 pm.jpg

[Carsten]

No, avoid J2K exports for reuse in DCP-o-matic - DCP-o-matic will not process these images and pass them through - but they are not compliant with DCI servers. Try DPX or TIFF.

- Carsten

[cloud06]

New version of Resolve (still in beta, v15) will support Kakadu-based JPEG2000 encoding. It should be faster and DCI compliant. Resolve will be able to export DCP directly this way (without any additional plugins), but I guess JPEG2000 files will also be an option.

[Carsten]

Hi skiff, don't know why you posted these screenshots specifically, but it appears that you created a DNxHR file with scope content letterboxed in a 3840/2160 (UHD) file. The right way to create a DCP from that is to configure a scope container under DCP. In Content/Video crop away the black bars (about 277pix from both top and bottom), and choose Scale to: Scope/2.39:1.

- Carsten