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

While OpenDCP to my knowledge is not known for specific J2K codestream issues, it is now somewhat outdated, and lacks many of the SMPTE DCP features of recent years. However - aside from the data rate, there may be another issue that we had on the DCP-o-matic forum many times: Some filmmakers chose to create the J2K image series or MXF file from within other applications, then use OpenDCP or DCP-o-matic for wrapping only (both OpenDCP as well as DCP-o-matic allow to bypass J2K encoding). In this case, the J2K encoder used can often not be traced back from the DCP created. In the past, very often Davinci Resolves JPEG2000 encoder has been used for this workflow. Many film makers using it assumed that the only use case for J2K images would be immediate DCP conversion. However, over the course of some Resolve versions, the JPEG2000 encoder clearly did not follow JPEG2000 D-Cinema constraints and created bad DCI codestreams. We had many reports of DCP-o-matic DCPs having sync issues, skipping, stuttering, etc,, and when asking more questions, it turned out they used Resolve or other tools to create the J2K files, and used DCP-o-matic only for wrapping. Note that Resolve at some point in time allowed to use an EasyDCP plugin with solid codestream compliance in addition to it's own non-DCI JPEG2000 encoder, and is now (I think from Resolve 15.x) using the Kakadu encoder/decoder, which so far is trouble free. Software decoders running on mainstream CPUs usually have no trouble to play these non-DCI compliant streams, as they mostly use a more solid decoder that allows a greater variety of J2K dialects. DCI servers use hardware decoders and lack that decoding flexibility. - Carsten -----Original-Nachricht----- Betreff: Re: [DCP-o-matic] Help diagnosing faulty DCP? Datum: 2020-01-25T21:46:45+0100 Von: "Jim Dummett via DCPomatic" &lt;dcpomatic(a)carlh.net&gt; An: "lilian" &lt;lilianlef(a)gmail.com&gt; Thank you Lilian! I will email you off list with a download link. Jim On 25/01/2020 20:43, lilian wrote: 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 < 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>