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

Hi Jim, Send me your package, I will check it with the most recent easydcp player. Lilian Le samedi 25 janvier 2020, Jim Dummett via DCPomatic &lt;dcpomatic(a)carlh.net <mailto:dcpomatic@carlh.net>> a écrit : Hi Carsten. Thanks for your reply. I'm waiting to hear back from the cinema about the server model. I'll report back when I find out. I agree that the J2K codestream is prime suspect, but I don't think data rate is the cause in this case. asdcplib reports the largest single frame as 833536 bytes, which works out to approx 160Mb/s. Incidentally, asdcplib also reports all the HMAC values verify OK too (using asdcp-unwrap's "-m" option). So I really am left scratching my head. I'm interested by your comment about experiencing a similar fault where playback "failed/skipped". When you say "skipped", do you mean it did exactly the same as what this DCP did - screen black for a second and then playback jumped forward abruptly? Jim On 25/01/2020 17:28, audiovisual(a)t-online.de <mailto:audiovisual@t-online.de> wrote: 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" &lt;dcpomatic(a)carlh.net <mailto:dcpomatic@carlh.net>> An: "carlh net dcpomatic" &lt;dcpomatic(a)carlh.net <mailto:dcpomatic@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 <mailto:DCPomatic@carlh.net> http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic <http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic>  _______________________________________________ DCPomatic mailing list DCPomatic(a)carlh.net <mailto:DCPomatic@carlh.net> http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic <http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic>