Re: [DCP-o-matic] Help diagnosing faulty DCP?

As the problem persisted after rewrapping, there is probably something wrong with the MXF file structure, or, more probable, with the J2K codestream. It is not easy to analyse these issues if they are of formal nature only. Is it possible to learn the type of server this DCP failed on? I recently had similar issues with a DCP that was created with a data rate of 230MBit/s. It failed/skipped on traditional Doremi/Dolphin based servers (DCP-2000/2K4), but had no issues on IMB/IMS, Sonys, or Dolby servers. The Dolphin weakness with peaking data rates is well known, but, as it seems, even a 'conservative' setting of 230MBit/s caused issues. A re-encoded DCP at 200 MBit/s did not show any issues on the same servers that failed before. Not saying that it is a data rate issue, but I DO KNOW that some film makers follow the 'bigger numbers is always better' in order to protect their precious images, and it is not unusual for them to willingly max out on data rate options.They may then test their DCP positively on some HFR or otherwise more capable system, check it 'okay', then it fails on some older servers. - Carsten -----Original-Nachricht----- Betreff: [DCP-o-matic] Help diagnosing faulty DCP? Datum: 2020-01-25T17:36:54+0100 Von: "Jim Dummett via DCPomatic" <dcpomatic(a)carlh.net> An: "carlh net dcpomatic" <dcpomatic(a)carlh.net> Hi all. Anyone out there have access to a Wailua or recent version of EasyDCP Player+, and be willing to run a DCP through it for validation? This DCP is a 3 minute short which failed playback at a London cinema recently. The fault was that picture and sound cut out (screen black, silence) for a couple of seconds and then playback resumed, but it skipped forwards by about 1 minute. This behaviour was replicated on two different servers at this cinema, although weirdly it played back faultlessly at another cinema. The disturbing thing is that I cannot find any fault with the DCP with the tools I have available. I would really like to find out what the fault is so I can add tools to our workflow to catch similar faults in future. NB This DCP came from an unknown external source and was made with OpenDCP. However, we rewrapped it with DCP-o-matic (without force J2K re-encode) and the problem persisted in that rewrapped DCP. If anyone is able to help, would be amazing. Many thanks, Jim _______________________________________________ DCPomatic mailing list DCPomatic(a)carlh.net http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic