I have doubts if the material is re-encoded.

[dcpforever]

Hello. This is my first participation in the forum. Despite having readed some threads, I still have doubts about the subject.
I usually use Assimilate Scratch to create the 2jc sequence with XYZ colors, which is DCI compliant. Therefore I hope that DOM respects this sequence and doesn't re-encode.
But, once the DCP is done, I realized of a mxf file in a folder called "video", a mxf file exactly equal to the video file in the DCP folder.
What is the point of this file? Has DOM re-encode the original 2jc sequence?

Thanks

[carl]

Hi,

It should certainly be easier to know for sure what DCP-o-matic has done with your data, and there's a to-do list item for that.

Are you getting a MXF file from Assimilate Scratch?

Assuming you don't change it (crop/scale/letterbox etc) the JPEG2000 data should be left untouched. It will be re-written into a new MXF file, so that DCP-o-matic can change the internal IDs etc. but the JPEG2000 data should be bit-for-bit identical. You can confirm this on the command line with something like `asdcp-unwrap`, if you're comfortable with that.

The file in `video` is to support resumption of encode jobs after crashes, and to allow already-computed data to be re-used.

[dcpforever]

Are you getting a MXF file from Assimilate Scratch?

Is not a mxf file, it is a sequence of jpeg2000 files, in XYZ color space.

All right, now I'm getting quieter, I no longer have the doubt

Thank you

[Carsten]

If you feed it j2k image sequences, DCP-o-matic will still copy these j2k's into an MXF file, that is what you see. But the j2k data within the MXF is, as Carl says, bit identical to the j2k series. The same would even be true if you feed it a fully DCI compliant MXF - it needs to be rewrapped into a new MXF file according to current project settings, but it is not re-encoded, but just 'reformatted'.

- Carsten