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

Dear Jim,

 

I'm afraid the full validation seems inconclusive either...

Le dim. 26 janv. 2020 à 00:44, Jim Dummett <j@dummett.org> a écrit :

Thank you very much Lilian.

EasyDCP's log seems inconclusive. j2c-test's output is interesting, but I don't know how to interpret the "Unprocessed markers". Perhaps Carl or someone else can shed light on that?

If I can trouble you further, would you be able to run EasyDCP's full validation on it? It seems to be a new feature recently added:

https://www.easydcp.com/support-faq.php?id=110

I don't think the 2 channels of audio is the cause. We rewrapped this DCP to Interop with 6 audio channels and that DCP behaved exactly the same as the original in the cinema.

In response to Carl's question: Yes, we also made a force J2K re-encode DCP from the original. DCP-o-matic did that quite happily - completed without error and nothing unusual in log, stdout, or stderr. That re-encoded DCP was successfully played at another cinema, but as yet I've not been able to test it at the venue where the original failed. I hope to be able to do that in the next week.

Thanks everyone for joining in with this detective work!

Jim

 

On 25/01/2020 22:43, lilian wrote:

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@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:

> 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@carlh.net
> http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic
>

_______________________________________________
DCPomatic mailing list
DCPomatic@carlh.net
http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic