Hi all.
Does anyone have any pointers on converting a 3D bluray to DCP? The
bluray which is the source in this case has the 3D encoded as MVC. From
my reading, this means the right eye picture is encoded as a separate
stream (which is a delta from the left eye).
Have ripped the bluray with MakeMKV which recognises that it's an MVC-3D
stream. And the file it outputs appears to be the right size so I think
MakeMKV is not dropping the extra stream or something like that.
But I haven't found any software that can display both eyes at present.
DCP-o-matic doesn't see it, and nor does Bino 3D player or VLC.
I'm on Mac but can get hold of a Windows box if I need to.
Anyone encountered this before?
Many thanks,
Jim
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
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
