26 Jan
2020
26 Jan
'20
12:36 p.m.
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:
Dear Jim,
I'm afraid the full validation seems inconclusive either...
Le dim. 26 janv. 2020 à 00:44, Jim Dummett <j(a)dummett.org
<mailto: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(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:
>
> > 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
> >
>
> _______________________________________________
> DCPomatic mailing list
> DCPomatic(a)carlh.net <mailto:DCPomatic@carlh.net>
> http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic
>