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> a écrit :

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> 

The playback does not fail. This player crashes when bitrate his higher than 250. Please find the log enclosed. Audio has only 2 channels with SMPTE content. I do not know if there is any restriction about it. I checked j2c structure with j2c-test but I do not know how to analyse the 'Unprocessed marker': SIZ: Rsize: 3 Xsize: 1998 Ysize: 1080 XOsize: 0 YOsize: 0 XTsize: 1998 YTsize: 1080 XTOsize: 0 YTOsize: 0 Csize: 3 Components 0: 11, 1, 1 1: 11, 1, 1 2: 11, 1, 1 COD: ProgOrder: CPRL Layers: 1 DecompLevels: 5 CodeBlockWidth: 32 CodeBlockHeight: 32 CodeBlockStyle: 0 Transformation: 9/7 QCD: QuantizationType: scalar expounded GuardBits: 4 SPqcd: 4 000000: 20 96 f0 96 f0 96 c0 8f 00 8f 00 8e e0 87 50 87 .............P. 000001: 50 87 68 70 05 70 05 70 47 77 d3 77 d3 77 62 P.hp.p.pGw.w.wb Unprocessed marker - COC: Coding style component Unprocessed marker - QCC: Quantization component Unprocessed marker - COC: Coding style component Unprocessed marker - QCC: Quantization component Unprocessed marker - SOT: Start of tile-part Processed 11 JPEG 2000 marker items. Le sam. 25 janv. 2020 à 23:07, Carl Hetherington via DCPomatic < dcpomatic(a)carlh.net&gt; a écrit :

I am not fluent in J2K, but to me it looks as if that codestream at least tries to be DCI compliant: --- Cinema2K profile: This option generates a codestream compliant to the Digital cinema specifications for a 2K resolution content. The value given is the frame rate which can be 24 or 48 fps. The main specifications of the JPEG Profile-3 (2K Digital Cinema Profile) are * Image size = 2048 x 1080 (at least one of the dimensions should match 2048 x 1080) * Single tile * Wavelet transform levels = Maximum of 5 * Wavelet filter = 9-7 filter * Codeblock size = 32 x 32 * Precinct size = 128 x 128 (Lowest frequency subband), 256 x 256 (other subbands) * Maximum Bit rate for entire frame = 1302083 bytes for 24 fps, 651041 bytes for 48fps * Maximum Bit rate for each color component= 1041666 bytes for 24 fps, 520833 bytes for 48fps * Tile parts = 3; Each tile part contains data necessary to decompress one 2K color component * 12 bits per component. --- It would be interesting to see the same J2C-test output for a current DCP-o-matic output file in comparison. Jim - is the metadata of the original DCP still available? Wondering wether the original MXF file contains some header data that may lead to the origin of the files? Although it is quite probable that it would just lead to OpenDCP. It may still be interesting to find the reason for this, but, in general, when I come across a non-working DCP, I first try to rewrap, and if that also fails, try to re-encode, and then forget about it. J2K and MXF is complex enough, and finding the actual cause will usually get you nowhere, at least when 'old' software has been used. A developer of current software of course, confronted with such an issue should be highly interested. --------------- I checked j2c structure with j2c-test but I do not know how to analyse the 'Unprocessed marker': SIZ: Rsize: 3 Xsize: 1998 Ysize: 1080 XOsize: 0 YOsize: 0 XTsize: 1998 YTsize: 1080 XTOsize: 0 YTOsize: 0 Csize: 3 Components 0: 11, 1, 1 1: 11, 1, 1 2: 11, 1, 1 COD: ProgOrder: CPRL Layers: 1 DecompLevels: 5 CodeBlockWidth: 32 CodeBlockHeight: 32 CodeBlockStyle: 0 Transformation: 9/7 QCD: QuantizationType: scalar expounded GuardBits: 4 SPqcd: 4 000000: 20 96 f0 96 f0 96 c0 8f 00 8f 00 8e e0 87 50 87 .............P. 000001: 50 87 68 70 05 70 05 70 47 77 d3 77 d3 77 62 P.hp.p.pGw.w.wb Unprocessed marker - COC: Coding style component Unprocessed marker - QCC: Quantization component Unprocessed marker - COC: Coding style component Unprocessed marker - QCC: Quantization component Unprocessed marker - SOT: Start of tile-part Processed 11 JPEG 2000 marker items. Le sam. 25 janv. 2020 à 23:07, Carl Hetherington via DCPomatic < dcpomatic(a)carlh.net <mailto:dcpomatic@carlh.net> > a écrit : Hi Jim It might be interesting to see if DCP-o-matic will happily make a new DCP out of it with "force J2K re-encode" ticked. Best Carl On Sat, 25 Jan 2020, Jim Dummett via DCPomatic wrote: EasyDCP Player+, cinema black, silence) forwards by servers at this cinema. with the fault is so I OpenDCP. re-encode) and <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> 

Hi Lilian. Thanks very much for doing that. Annoying that it's not revealing the cause, but also useful to know this is not an obvious fault. I have run j2c-test on every individual frame and got no errors and completely uniform output for each frame (including the "Unprocessed markers"). I am not sure if the "Unprocessed markers" are telling or not, as running j2c-test on a DCP-o-matic-made DCP, which I believe to be good, also outputs "Unprocessed marker - SOT: Start of tile-part". I guess next step is to try to get this DCP validated with a more heavy duty tool like Wailua, and see if it find errors. I don't suppose anyone can help with that by any chance? Many thanks, Jim On 26/01/2020 08:03, lilian wrote: