26 Jan
2020
26 Jan
'20
9:03 p.m.
So, maybe it was indeed Resolve. There are other options as well, Adobe products, JPEG2000
plugins for Adobe products.
- Carsten
Am 26.01.2020 um 16:34 schrieb lilian:
It seems the mxf was only wrapped with OpenDCP:
asdcp-info -i -d returns
SMPTE 429 file essence type is JPEG 2000 pictures, (6737 edit units).
ProductUUID: 43059a1d-0432-4101-b83f-736815acf31d
ProductVersion: 0.30.0
CompanyName: OpenDCP
ProductName: OpenDCP
EncryptedEssence: No
AssetUUID: 1ee2949c-c2ef-46f5-b5c5-738109994496
Label Set Type: SMPTE
AspectRatio: 1998/1080
EditRate: 24/1
SampleRate: 24/1
StoredWidth: 1998
StoredHeight: 1080
Rsize: 3
Xsize: 1998
Ysize: 1080
XOsize: 0
YOsize: 0
XTsize: 1998
YTsize: 1080
XTOsize: 0
YTOsize: 0
ContainerDuration: 6737
-- JPEG 2000 Metadata --
ImageComponents:
bits h-sep v-sep
12 1 1
12 1 1
12 1 1
Scod: 1
ProgressionOrder: 4
NumberOfLayers: 1
MultiCompTransform: 1
DecompositionLevels: 5
CodeblockWidth: 3
CodeblockHeight: 3
CodeblockStyle: 0
Transformation: 0
Precincts: 6
precinct dimensions:
1: 128 x 128
2: 256 x 256
3: 256 x 256
4: 256 x 256
5: 256 x 256
6: 256 x 256
Sqcd: 66
SPqcd: 972096f096f096c08f008f008ee087508750876870057005704777d377d37762
j2c-test does not give the same result between Jim's DCP and J2K created with
OpenDCP.
Jim's DCP:
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.
OPEN DCP 0.30.0:
SIZ:
Rsize: 3
Xsize: 1920
Ysize: 1080
XOsize: 0
YOsize: 0
XTsize: 1920
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
COM:OpenDCP
Unprocessed marker - SOT: Start of tile-part
Processed 12 JPEG 2000 marker items.
DOM 2.14.17:
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
COM:libdcp
Unprocessed marker - SOT: Start of tile-part
Processed 8 JPEG 2000 marker items.
Le dim. 26 janv. 2020 à 15:13, audiovisual--- via DCPomatic <dcpomatic(a)carlh.net> 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> 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
http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic
_______________________________________________
DCPomatic mailing list
DCPomatic(a)carlh.net
http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic
_______________________________________________
DCPomatic mailing list
DCPomatic(a)carlh.net
http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic 
30 Jan
30 Jan
6:52 p.m.
New subject: [DCP-o-matic] Help diagnosing faulty DCP?
Hi Carsten and Lilian.
Sorry I've gone silent - I've been off sick for a few days. Thanks loads
for pursuing this in such depth.
I spoke to the guy who made the DCP. It turns out the workflow used to
make the DCP was this:
ProRes422 file -> Resolve to convert to J2K image sequence -> OpenDCP to
package DCP.
So you were right!
I think some emails in this chain have not come through to me though.
Can I ask, why did you suspect Resolve? Is Resolve known for creating
non-compliant J2K codestreams?
NB The DCP-maker was not able to remember what version of Resolve he
used, and does not still have the project files.
One other thing: Carsten said "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."
I agree, there's only so much you can do.
However, my real purpose is this: This DCP passed our validation tests,
but went on to fail in the cinema. So, as it stands, I have no way of
knowing if any other DCP we send out to cinemas may have the same fault.
The first step to plugging that gap is to figure out exactly what is the
problem with this DCP, and then I can go about assembling tooling to
spot it in any other DCP.
Thankfully, happenings like this are extremely rare - I last saw
something like this 3 years ago, so it's approx 1 in 3000. But that's
still 1 more than I'd like.
Thanks again for all your help with this.
Jim
On 26/01/2020 21:03, Carsten Kurz via DCPomatic wrote:
So, maybe it was indeed Resolve. There are other
options as well,
Adobe products, JPEG2000 plugins for Adobe products.
- Carsten
Am 26.01.2020 um 16:34 schrieb lilian:
It seems the mxf was only wrapped with OpenDCP:
asdcp-info -i -d returns
SMPTE 429 file essence type is JPEG 2000 pictures, (6737 edit units).
ProductUUID: 43059a1d-0432-4101-b83f-736815acf31d
ProductVersion: 0.30.0
CompanyName: OpenDCP
ProductName: OpenDCP
EncryptedEssence: No
AssetUUID: 1ee2949c-c2ef-46f5-b5c5-738109994496
Label Set Type: SMPTE
AspectRatio: 1998/1080
EditRate: 24/1
SampleRate: 24/1
StoredWidth: 1998
StoredHeight: 1080
Rsize: 3
Xsize: 1998
Ysize: 1080
XOsize: 0
YOsize: 0
XTsize: 1998
YTsize: 1080
XTOsize: 0
YTOsize: 0
ContainerDuration: 6737
-- JPEG 2000 Metadata --
ImageComponents:
bits h-sep v-sep
12 1 1
12 1 1
12 1 1
Scod: 1
ProgressionOrder: 4
NumberOfLayers: 1
MultiCompTransform: 1
DecompositionLevels: 5
CodeblockWidth: 3
CodeblockHeight: 3
CodeblockStyle: 0
Transformation: 0
Precincts: 6
precinct dimensions:
1: 128 x 128
2: 256 x 256
3: 256 x 256
4: 256 x 256
5: 256 x 256
6: 256 x 256
Sqcd: 66
SPqcd:
972096f096f096c08f008f008ee087508750876870057005704777d377d37762
j2c-test does not give the same result between Jim's DCP and J2K
created with OpenDCP.
Jim's DCP:
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.
OPEN DCP 0.30.0:
SIZ:
Rsize: 3
Xsize: 1920
Ysize: 1080
XOsize: 0
YOsize: 0
XTsize: 1920
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
COM:OpenDCP
Unprocessed marker - SOT: Start of tile-part
Processed 12 JPEG 2000 marker items.
DOM 2.14.17:
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
COM:libdcp
Unprocessed marker - SOT: Start of tile-part
Processed 8 JPEG 2000 marker items.
Le dim. 26 janv. 2020 à 15:13, audiovisual--- via DCPomatic
<dcpomatic(a)carlh.net <mailto:dcpomatic@carlh.net>> 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:
_______________________________________________
DCPomatic mailing list
DCPomatic(a)carlh.net
http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic 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
_______________________________________________
DCPomatic mailing list
DCPomatic(a)carlh.net <mailto:DCPomatic@carlh.net>
http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic
1914
days inactive
1918
days old
1 comments
2 participants
participants (2)
-
Carsten Kurz -
Jim Dummett