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

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