Some tips on downloading and uploading DCPs and large files

Before uploading a DCP, ask the cinema or festival how they want it delivered. If they provide an upload server or delivery portal, use that and follow their instructions. Agree on the deadline as well. The cinema needs time to download, ingest and test the film, and a replacement upload can take just as long as the first one.

Try to deliver two or three weeks before the screening where possible, or earlier if the festival asks for it. Keep the original files until the recipient has confirmed that the delivery is complete and has passed verification.

Uploading to MovieTransit

MovieTransit is one option for delivering DCPs to cinemas in Norway. Uploads currently use FTP. Use the server address, username, password and destination folder supplied for the delivery, and confirm which cinemas should receive the package.

When transferring a DCP by FTP, set the transfer type to Binary for all files, including XML. ASCII mode can change line endings in the XML files. The files may still open normally, but their checksums will no longer match. A small XML file can stop a delivery from passing verification even when all the large MXF files arrived correctly.

In FileZilla, select Binary explicitly rather than leaving the transfer type on Auto. Follow the server’s connection instructions; passive mode is commonly used for FTP. When the queue finishes, check for failed transfers and confirm that every file in the DCP folder was uploaded. Keep the folder structure intact.

Other ways to send large files

For other deliveries, the recipient may provide IBM Aspera or Signiant Media Shuttle. These systems are used for large media files such as DCPs and ProRes masters. Install the transfer application requested by the recipient and use the supplied portal. Aspera uses its FASP transfer technology; Media Shuttle provides portals for sending and receiving files with controlled access.

Filemail is another option when you need to send a download link. Check that the plan accepts the size of your delivery and that the link will remain available long enough for the recipient to download it. For large transfers, check the desktop application’s resume options before starting, so an interruption does not mean starting the whole upload again.

The speed depends on both ends of the connection. A fast transfer service cannot make a slow home upload connection faster, and the cinema may be downloading several films at once. Test the connection before a time-critical delivery and leave room for a retry.

Using a dedicated server

If you send or receive large files regularly, a dedicated server lets you manage the storage and user accounts yourself. Ubuntu Server LTS with SFTP access is one possible setup. Hetzner’s server auction is one place to look for a machine. Compare the disks, network connection and traffic terms of the actual offer; storage capacity and monthly price vary between configurations.

A server with a 1 Gbit/s connection shares that bandwidth between its active transfers. If several cinemas download at the same time, each transfer gets part of the available capacity, and the connection at the cinema may be the limiting factor. Allow enough storage for incoming deliveries and files that still need to remain available for download.

Clients such as Cyberduck, FileZilla, WinSCP on Windows and Transmit on macOS can connect by SFTP. Give the recipient the hostname, port, username and password or SSH-key instructions. SFTP normally uses port 22. FTP and SFTP are different protocols, so make sure the recipient selects the one the server provides.

You also have to maintain the server: install security updates, configure the firewall, restrict accounts to the required folders and watch the free disk space. Keep backups of the files and configuration you cannot afford to lose. Include that work when comparing a server with a managed transfer service.

Checking the files after downloading

A completed transfer queue tells you that the client finished its work. To check that the files arrived unchanged, compare their checksums with values recorded before the transfer. Two files can have the same size and still contain different data.

A DCP already contains a PKL (Packing List) with hashes for the assets it lists. A DCP hash checker calculates those hashes again and compares them with the PKL. In easyDCP Player, open the DCP and run the Hash Checker. Let the check finish and read the results before treating the package as ready for screening.

I also have a PKL Hash Checker on tools.dcpformat.net. Select the files and paste the PKL to compare their hashes, or paste a checksum manifest supplied by the sender. The file hashes are calculated in your browser, so the files do not have to be uploaded again just to check them.

If a file fails verification, check the source copy as well. A file that was already wrong before uploading will still be wrong after another transfer. If the source passes and the received copy fails, resend the affected file. For an XML mismatch after FTP delivery, check that Binary mode was used.

Sending a checksum manifest

A ProRes master, a folder of WAV files or an image sequence does not come with a DCP packing list. For these deliveries, send a checksum manifest with the files. It records a checksum and relative path for each file, giving the recipient something to compare the downloaded copy against. Generate it from the final source files before uploading.

My Checksum Script Maker creates matching scripts for making and verifying a manifest. Choose SHA-256, or MD5 when required by the recipient, and download the scripts for Windows or macOS/Linux. They run locally in the delivery folder.

Put the creation script in the top folder of the delivery and run it. It includes files in subfolders and writes the manifest beside them. Remove the creation script before uploading, and send the files with the manifest. If you change or add a file afterwards, regenerate the manifest. The recipient can use the matching verification script or the browser-based hash checker to check the received files.

For a DCP, an additional delivery manifest can help check the transferred files, while verification against the PKL remains part of checking the package itself.

Compressing files before uploading

Uncompressed video, TIFF or DPX sequences and WAV files may become smaller when packed into a RAR or 7z archive. How much smaller depends on the material. Try a representative sample first; a fixed compression percentage does not tell you much about the files you are about to send.

The picture data in a finished DCP is already compressed, so an archive will usually offer less benefit there. It can still keep a package together as one download, but check that the recipient accepts archives. A cinema expecting a DCP folder should not have to find an extraction tool just before ingest.

Keka on macOS and WinRAR on Windows are options for working with archives. Depending on the format, you can split a large archive into parts or protect it with a password. WinRAR can also add a recovery record to help repair some archive damage. Keep the original files anyway, and test the archive after creating it.

Include compression and extraction time in the delivery schedule. The recipient also needs disk space for both the archive and its extracted contents. If compression saves little space but adds hours at both ends, sending the original files may be quicker.

Checking the DCP before delivery

A hash check cannot tell you whether the subtitles are in the right language or the dialogue is in sync. Play through the DCP before sending it, and arrange a cinema test where possible. Check the picture format, subtitle placement, audio channels and sync against the version that is supposed to be screened.

The name should describe that same version. A Flat DCP labelled Scope can lead the projectionist to select the wrong format. Check the content type, aspect ratio, language codes and version information. My DCNC Name Generator can build a name or validate an existing one; the fields are explained in Making a DCNC DCP name.

Use Flat (1.85:1) or Scope (2.39:1) as agreed with the cinema. If the film has another aspect ratio, place it inside the appropriate container and identify it correctly. Do not assume a Full Container DCP will be projected as intended without checking with the venue.

Watch for subtitles that are too close to the picture edges, overlap other text or drift out of sync. Listen for distortion and check that the sound comes from the intended channels. Save the verification report and note which version was tested.

Sending the end-credit times

Along with the DCP, it is common to send the times for the start of end credits and the start of moving end credits. These can be different points: a film may begin its credits with static cards and only start the rolling credits later. The cinema can use the times when programming house lights and other cues.

In a SMPTE CPL (Composition Playlist), these points can be recorded as FFEC, First Frame of End Credits, and FFMC, First Frame of Moving Credits. My Credit & Clip Markers tool reads the marker track from a CPL and shows the timecodes and how long before the end each marker occurs.

Use the CPL from the version you are delivering, and include the frame rate when sending the timecodes separately. If the CPL has no credit markers, identify the points during playback and send the times to the cinema. The cinema still decides how to use them in its show automation.

Checking the KDMs

An encrypted DCP needs a KDM for the intended playback server and the correct composition. Its validity window must cover the test as well as the screening. A KDM that starts at the public screening time will not help the projectionist test the film the day before.

My KDM Wallet displays the validity windows of multiple KDMs on a timeline, grouped by composition, and flags expired keys and those approaching expiry. You can also load the screen server’s public PEM certificate to check which KDMs target that device. The content keys remain encrypted.

This is useful when several versions, screens or screening dates are involved. Check the composition, recipient and validity period against the actual booking. If the KDM does not cover it, ask the issuer for a replacement before the test.

Including a delivery note

Send a delivery note with the files so the cinema can identify the package and contact the right person if something is missing. Include the exact version being delivered, the recipient, contact details and who supplies any KDMs. Add the end-credit times and frame rate to the notes.

My Delivery Note tool reads a CPL and, optionally, a PKL. It collects the content title, CPL UUID, runtime and reel information; the PKL adds asset sizes and hashes. Add the sender and delivery details, then print the note or save it as a PDF through the browser. The XML is read locally in the browser.

The CPL UUID is particularly useful when two versions have similar names. Include it in the delivery note so the cinema and KDM issuer can refer to the same composition without guessing from a filename.