Dolby DSS200 and test version

[Carsten]

Solved - turns out that only one specific DCP among multiple created with the same version of DCP-o-matic caused problems. And it wasn't the openjpeg bug we had in 2.11.21-33. They used a very old version of DCP-o-matic, and created SMPTE DCPs. But that wouldn't have caused issues, as far as I remember there have only very rarely been DCP-o-matic versions in the wild that created bad DCPs, and if so, only for a very short time, and only test versions.

Turned out that it was actually a copy/media error, the video.mxf is corrupt. Now, the Sony server is to blame because it could have detected bad data during ingest. As reported, the Sony choked a bit on ingest, but still offered to play the bad DCP. BOOOOOH!

@Carl - this DCP causes an error (and crash) when played with DCP-o-matic player ('could not read video frame'). The 'Verfify DCP' Function in 2.13.13 still says it is okay. I assume that verify function is not fully 'functional' yet, reading through the files and comparing hashes?


- Carsten

[carl]

Verify DCP is supposed to work... I'll have a look at that.

I don't know exactly how despondant to feel about the fact that a production playout server is not checking hashes on ingest. It's ridiculous

[Thienhuynh]

Hi everyone, I'm new here and i may have same problem with op.

I used an old version of DoM (i don't remember which version it is, it had different icon from now) and made a DCP for 54 cinemas.
52 of them are played fine but there are 2 cinemas change device recently have playback problem, the playback repeatedly stuck fews second for both video and audio.
Those two used Dolby DSS220,my OS is MacOS 10.11.6
I downloaded newest version of DoM ( 2.12.4 ) and created another DCP but still had same problem. I make the DCP from an unencrypted DCP (the studio gave me) not from a video file, I just burn the subtitle in and encrypt the DCP.

[Carsten]

Hmm. Are you sure that of these 54 cinemas, only those two are using Dolby DSS220? Or are there other sites using DSS220 without playback issues? Note that the relevant part in this case is the CAT745, the media block. All DSS220 systems use the CAT745 media block, while there are DSS200 systems that use the 'old' CAT862 (mostly), and some use the CAT745. If there is an issue with the J2K files, ALL CAT745 systems should be affected, DSS200 as well as DSS220. Another reason for possible differences could be the software version of these systems. Maybe you can find out about them.
What is the frame rate of this DCP? Different Dolby software versions supported different frames rates, and not all of these changes resulted in a clear 'yes/no', but may actually have been a 'solid/unreliable' situation.

If you re-use an existing DCP and omit J2K encoding, the issue is probably with the initial unencrypted DCPs media assets. Can you look into this DCP metadata (PKL, CPL, etc.) and tell us which mastering/encoding system was used? You will usually find that within the first few lines of these files. You can also safely quote these parts here on the forum.

Worst case would be if the unencrypted original DCP has been encoded with DCP-o-matic test version 2.11.23-33

You may try to diagnose the problem when you supply a test DCP to these sites created with DCP-o-matic 2.12.x, but with forced re-encoding. That would quickly tell what the problem is.

- Carsten

[Thienhuynh]

Thank Carsten, I need to tell you that the problem happen weeks ago, so it's kinda late for me to send another test DCP.

You're right, only those 2 cinemas used CAT745, it's not strange if almost all cinema from my country use old version
The original DCP and my DCP use 24 fps, audio 5.1, 2k scope. I checked metadata from original DCP, look like it's encoded by EasyDCP (I can't find which version of it).

Tell me more about "forced re-encoding", if I use ffmpeg or DoM export feature and then encode the video back to DCP with DoM 2.12.x, will that fix the problem?

[Carsten]

I think the easiest way to re-encode is to change a more or less irrelevant image parameter that hit's all frames. That way, DCP-o-matic is forced to recompress all frames, instead of passing them through. You don't need to export/reimport.
I am not 100% sure about all possible ways to trigger this. Maybe it would be possible by e.g. introducing something like an invisible burn-in subtitle. I would love to have something like a checkbox upon 'Make DCP' that offers me to recompress or pass through. Maybe Carl reads this and can suggest something.

For now, I would crop a single line away from either side or top/bottom. As this will recompress, and you don't want an unnecessary loss of quality, make sure you set compression data rate to at least 200Mbit/s, my preferred choice is 230-240Mbit/s. That is still safe for all servers. Your quoted DCP parameters are safe, I would love to hear if the recompressed version plays better on the CAT745 systems.

- Carsten