Same DCP, different issues with different Servers

[PaoloCellammare]

Hi,
I made a feature film (91min lenght) and I'm in the middle of a tour to screen it in several different theatres in my country (Italy).
The first projection on a Doremi server was just perfect. The theatre was the famous Arcadia di Melzo, Sala Energia, so I was pretty confident I wouldn't have any problem with them.
I was very happy after that event but then I projected it in a different theatre that had some frame drop in the image.
I still couldn't find out yet what server was it on, the issue was present but it wasn't huge and the audience mainly didn't notice it (even if I was dying).

Next one was a theatre that had 2 different sever system and got huge problems on both: on the Sony XCT-S10 (latest fw) it got progressively out of synch after seconds of projection. If we skipped to a different part of the movie it got synched and then progressively losing it.
On the other server they had, a Dolby DSS200 it got huge frame drops on the video and it wasn't projectable that way.
We had to use and emergency mp4 file from a laptop, scrificing quality and 5.1 mix. I was so miserable.

I would like to prevent further problems on the next projections, but I only know we will face a different systems on each event.
The next one will be a Cinecloud server.
Then we will have a Christie server (sw ver. 1.5.3.5), and a GDC D-Cinema Server with IMB sw ver OS-SA-3K-3.0.8.0
There will be also more Sony XCT-S10 servers and I don't know yet about the other 4 theatres missing on the list.

I am a filmmaker and I don't know much about D-Cinema, I was trying to do everything in the most correct way but every time we have to project that poorly the movie I put so much effort in doing my heart sinks.

I made the DCP from a Jpeg2000 sequence and 6 Wav PCM files (24bit 48khz). It is 24 fps and the video is encoded at 230Mbps.
The only thing I can think about trying is to make a lighter encoding at 190Mbps. Do you think this could help?

I hope someone can help me to get the best results in the next screenings.
thank you very much

Paolo Cellammare

[Carsten]

I heard about these sync issues before - but only when non-DCI compliant J2K streams have been used. e.g. j2c from Resolve. J2k allows for many variations of the encoding. When DOM creates J2C, it uses special dcinema profiles in OpenJPEG to make sure the J2C is DCI compliant. When you import pre-existing J2C into DCP-o-matic to be used without re-encoding, the datarate setting in DOM is irrelevant. DOM is just passing through the J2k images. I guess that's what you had intended when you created your master as a JPEG2000 image series, instead of e.g. TIFFs.

So I guess you used JPEG2000 from another application, like Resolve, Premiere, or a J2K post processor, and ran them through DCP-o-matic without re-encoding. This most likely is the reason for your problems. Some servers choke on non-compliant J2C, some not, some earlier, some later.

I'm wondering wether DCP-o-matic should catch this condition - no-encoding, and issue a hint towards potential problems.

You have to recreate the DCP, I'd say. I don't see any workaround, as the behaviour of DCI servers with this DCP will simply be unpredictable.
The question is, how do you do this while you are on your tour...
What type of machine do you have available?

If you don't have access to an uncompressed source anymore, a workaround would be to reuse the existing J2K sequence or the existing DCP (MXF). You just need to force DOM into re-encoding the image. Yes, you would have two compression runs, but at the initial bitrate you selected, and with a similar setting in DOM for the reencoding, you will hardly notice it.



- Carsten

[PaoloCellammare]

Thank You for your Reply

As you predicted I was using J2Ks from Resolve and so this must be the issue. I will not have much time but I will try to create a new one on the fly using the correct workflow.
I will update the results.

Thank you very much
Paolo

[PaoloCellammare]

My odissey is starting to look endless...

I have a couple of days before leaving again for the tour and I tried to export TIFF XYZ 16bit from Resolve.
Before, when I was exporting JPEG2000 from Resolve, colours looked shifted in the display during encoding preview, but then they looked OK on D-o-M.
Now when I import the new TIFF sequence in D-o-M its colours look shifted in the display. This made me worry.

I selected conversion: NONE because it was XYZ already, as it says on the manual.
I started encoding it and paused to test the file with Stereoscopic Player that usually shows me the correct colors, but it didn't. Colors looked shifted and I don't know if it is because the file is not completed and it lacks the data to lead the software to interpret it, or not.

Now I am proceeding with the encoding (9hours) and I hope it will play fine at last.
Can you tell me if my workflow is correct?

thanks a lot

Paolo

[Carsten]

Stereoscopic player (at least the version I know) does not do proper color display.

However - you can load a DCP, or partial DCP, right into DCP-o-matic again (add folder). If it looks okay there, it is okay.

Keep in mind, DCI XYZ does not only include an XYZ conversion, but also a gamma correction for DCI gamma. If you choose 'none' in DOM, your exported footage needs to contain that gamma adaption already. This gamma adaption may lead to a greenish tint in highlights already. I do have Resolve on my machine for some testing, but I can't tell you wether the XYZ-TIFF export is immediately targeted at DCI.

I can not tell you for sure that what you did is correct. You would need to compare critical parts of your footage with the J2k/DCP you used initially to make sure color conversion and gamma is correct. If you have time enough, I would play safe and also do a full recompression on the J2k or initial DCP - even if that involves recompression. You will not notice the difference to the TIFF->J2K at 230MBit/s.

If you load a DCP-MXF videofile into VLC and perform a snapshot, the resulting grab will also show proper color rendition. There are other demo preview options as well. As you mention Stereoscopic player, I assume you are running windows. So you could also load NeoDCP player trial.

I guess I have to do some tests with Resolve myself to get a better idea about what is happening with XYZ exports.
This is an older thread, but as you can see, Resolves offers no 'simple' way to create DCI compliant J2K or TIFFs:

https://forum.blackmagicdesign.com/view ... f=3&t=7079

We had a similar Issue on the DOM mailinglist recently, and I can only repeat what I wrote there - when outputting a master from your grading or editing software, create the master universal, that is, in clear defined, 'usable' color spaces and formats. I guess I understand the ratio of wanting to let Resolve do the color conversion, but, in my opinion, there is not a clear or 'simple' interface between Resolves XYZ (TIFF or J2K) and a DCI/DCP mastering app. So, better output RGB, dpx, etc. from Resolve, and let DCP-o-matic do the full job of DCP conversion.

- Carsten

[Carsten]

Exactly which version of Resolve are you using?

- Carsten

[PaoloCellammare]

I used Resolve 12.5
Encoding just finished, the generated DCP looks like it's a working one... at least on my PC. The only issue is that it is darker than it should, like there is a shift on the Gamma. I realized that it is like that in the TIFF export compared to the J2K one, also from Resolve. This is quite weird.

The only thing I can do now is to make one more DCP while I will be sleeping, using the J2K files and forcing a re-encoding (I will add a black 1 pixel line on the bottom of the image cause I don't know what other way I have to force the encoding).

I hope for the best cause tomorrow in the morning I have to send those drives.

thank you

[carl]

For what it's worth at this stage, I would also drop your J2K data rate significantly. 250Mbit/s is the absolute maximum and I have heard stories of problems at rates near that. I would make a DCP at 100Mbit/s and at least have it ready as I don't think you'd see any degradation in the image and you'd be much less likely to see problems such as dropped frames.

[Carsten]

Please check the version number exactly - 12.5.x?

I had a look into resolve and I can see why and how people choose JPEG2000 or TIFF XYZ, but neither offers any options to define the parameters of the conversion. From what I read in BMD user forums, neither option is immediately compatible with DCI. Probably TIFF RGB is the better choice to forward to DCP-o-matic.

The only thing I can do now is to make one more DCP while I will be sleeping, using the J2K files and forcing a re-encoding (I will add a black 1 pixel line on the bottom of the image cause I don't know what other way I have to force the encoding).

After you reimport the video and audio MXF of the initial DCP (or the J2K sequence), you can set scaling to 'no stretch' or 'no scale' and set a crop of 1 pixel top or bottom. That will introduce a one pixel black line, but will not introduce any scaling. That will force DOM to recompress. If you are concerned about recompression, set the bitrate to 230MBit/s. That will keep it safe even for the very sensitive older Doremi servers.

From what I read, it seems the issue with Resolves JPEG2000 is not only the bitrate, as e.g. the mentioned Sonys can easily cope with 500MBit/s HFR rates, but the wrong J2K profile. Many people only verify the DCP with software players. They are inherently more stable than hardware decoders in DCI servers and deal with more J2K variations. Also, very often a check in software players will not reveal the occasional glitch or async build-up seen within a real full length presentation in a cinema with audience and a nervous filmmaker.

This is bad, as people then tend to blame DCP-o-matic, while in fact, the issue is caused by other software.

- Carsten

[PaoloCellammare]

Unfortunately RGB would loose part of the colors I have on my project, being it a narrower color space than XYZ (am I right?)
I proceeded as you said forcing the encoding with a 1 pixel black line on the bottom (I figured it out by myself). The DCP I made looks fine, I'm gonna send it as soon as I copy it on the drives. Let's hope for the best.

thank you very much for your support

I will update this thread with the results.

Paolo