Recreate DCP CPL and PKL XML files

[David Ferguson]

I've been given a DCP (a short unencrypted one) where the CPL and PLK metadata XML files have gone missing, leaving me with just the two MXF files - one for picture and other for audio. How can I recreate the XML files to be able to load and play it? I had a look and couldn't see an easy way of doing this. DCP-o-matic will load the MXF files but then transcodes them (ironically into a larger file), and I'd like to avoid any unnecessary transcoding if possible!

I thought maybe I could write the XML files manually, so I had a look at a couple of other sample DCPs I have lying around. It seems I need to generate:
- UUIDs for the PKL file, the CPL file, and the reel
- hashes for the two MXF files
But I'm unsure of how the UUIDs are generated, and what hashing algorithm(s) can be used.

Any help would be appreciated!

[Jon Dent]

UUID can be generated by a small Python file. It's just a randomly generated string of digits that is virtually guaranteed to be unique to that file

Hash is Base64 encoding of an SHA-1 checksum of the file. That can also be done with Python:

Hash:

import sys
import hashlib
import base64

# BUF_SIZE is totally arbitrary, change for your app!
BUF_SIZE = 65536 # lets read stuff in 64kb chunks!

sha1 = hashlib.sha1()
file_path = #path to file you want to hash
with open(file_path, 'rb') as f:
while True:
data = f.read(BUF_SIZE)
if not data:
break
sha1.update(data)

print(base64.b64encode(sha1.digest()))

UUID:

import uuid

print(uuid.uuid4())


Honestly though the easiest is to let DCP-o-Matic do it. It may transcode to a new MXF file but if the image and audio data is correct it won't recompress anything. Manually creating CPL and PKL files is just asking for trouble IMHO

edit: you can also try OpenDCP. It's old and unmaintained but it has a modular assembly method in that it'll read existing MXF files and generate CPL and PKL files for them.

[David Ferguson]

Honestly though the easiest is to let DCP-o-Matic do it. It may transcode to a new MXF file but if the image and audio data is correct it won't recompress anything.

Well that's what I'd hoped for, but as mentioned the file sizes of the output were about 1gb greater than the input - so it's certainly done something!

But thanks for the recommendation of OpenDCP - it seems to do exactly what I was looking for!

[Jim Cassedy]

I've had to do this sort of thing to 'fix' a number of amateur DCP's at various film festivals.
(Just because people can make their own DCP's, doesn't mean they should)
For shorts films it's usually not too much trouble to take the video & auidio mxf's
and have DCP-O-MATiC do it's magic to make a working DCP. I once had to do it
on short notice with a feature that was sent from a foreign country, and there wasn't
enough time for them to make & ship another DCP before the play-date, which was
sold out. It did take some time, but I managed to get it to the venue for their show.

[Carsten Kurz]

DCP-o-matic will NOT transcode/recompress if you set the NEW DCP parameters according to the MXF files. So, check resolution/container, frame rate, number of audio channels, and adjust all to source file parameters. DCP-o-matic will then just 'rewrap', but not recompress. Use the latest stable release for full SMPTE DCP support. Although you are free to create an interop DCP just as well.

You may get into trouble, though, if image and audio use different entry points (may happen with some DCPs). That offset would have been established in the (lost) CPL.
This would result in audio being out of sync. If audio file and video file have the same length (check properties or timeline view), you should be safe, though. Otherwise, you may need to trial and error towards a proper sync point by adjusting audio start position in DCP-o-matic.

[Jon Dent]

DCP-o-matic will NOT transcode/recompress if you set the NEW DCP parameters according to the MXF files. So, check resolution/container, frame rate, number of audio channels, and adjust all to source file parameters. DCP-o-matic will then just 'rewrap', but not recompress. Use the latest stable release for full SMPTE DCP support. Although you are free to create an interop DCP just as well.

You may get into trouble, though, if image and audio use different entry points (may happen with some DCPs). That offset would have been established in the (lost) CPL.
This would result in audio being out of sync. If audio file and video file have the same length (check properties or timeline view), you should be safe, though. Otherwise, you may need to trial and error towards a proper sync point by adjusting audio start position in DCP-o-matic.

I tried it out for shits and giggles and it looks like DoM does transcode the MXF files into new MXF files, even when the content itself is not altered. This is noted by the different file names and sizes in the DoM DCP vs the original, although in my case the DoM MXF files were slightly smaller.

[Carsten Kurz]

It does rewrap. Has to, because it needs to make sure the new MXF is formally correct. But rewrapping is not re-encoding. If you create a new DCP from a video MXF that uses a different container size, resolution, frame rate, etc., DCP-o-matic simply HAS to recompress, because the image needs to be scaled, cropped, resampled, whatever.

Rewrapping, you can also convert unencrypted to encrypted, or Interop to SMPTE, or vice versa, all without re-compression. Rewrapping goes at file read/write speed.

[Jon Dent]

I was using the terms 're-wrapping' and 'transcoding' interchangeably, as it appears that's the terminology DoM uses.

[Carsten Kurz]

Yeah, transcoding is not too accurate a term here. One would probably also need to differentiate between MXF data and full DCP file set.