Splicing a DCP (insert edit)

Anything and everything to do with DCP-o-matic.
Post Reply
binba
Posts: 11
Joined: Thu Jul 04, 2019 3:56 am

Splicing a DCP (insert edit)

Post by binba »

Couldn't find here a discussion about making small edits to an existing DCP. I'm talking about instances where a DCP has been created, but the film's producers want to change a few seconds in the middle. Without reels and CPLs, just patch an existing reel.
Since a DCP is an MXF with a series of intra-frame J2K frames, it's completely doable (correct me if I'm wrong).

One way to implement this is outside of DOM, which could work if one renders the J2K frames externally. But we know that this is a tricky thing, and it's better to trust DOM's J2K conversion.
So I see it as big feature request (a boy can dream)... supply a matching piece of source video, accurately define the splice point, and be able to verify it. (Audio is a slightly different beast - may need the ability to add 1ms crossfades to avoid pops, or just redo the audio track since they're much smaller and faster to work with.)

What do you think?
Carsten
Posts: 2648
Joined: Tue Apr 15, 2014 9:11 pm
Location: Germany

Re: Splicing a DCP (insert edit)

Post by Carsten »

viewtopic.php?f=2&t=1366

viewtopic.php?f=2&t=774&start=20

DCP does support arbitrary edits, even on the single frame level. However, we usually recommend to go the VF route carefully. Simply because, the more complicated a CPL structure becomes, the higher the risc of playout issues. So, while you MAY do changes on the DCP/CPL level, it is better to create a new 'clean' DCP afterwards. The only 'real' justification to do such things on the VF level is if a DCP has been distributed wide already, and there'd be no chance to send a new fully functional DCP before a screening. Then, sending a VF by email/dropbox would be a last resort. We have seen that happening for commercial releases a few times.

I have some limited experience with editing/splicing DCPs because sometimes I want to get rid of certain short pieces from a trailer, like 'Now in 3D', or 'In theatres summer 2017', sometimes witten, sometimes spoken. As these are short trailers, and in their modified form usually only meant to be played in our own cinema, I usually try to do these edits within DCP-o-matic, but then recreate a complete/autonomous DCP from them. Usually, I notice that kind of issue with the trailer only shortly before putting them into our show playlist, and the PC that I use for this at our cinema has no video editor (just Audacity). So, and also because it is an interesting challenge, I usually try to use only DCP-o-matic for achieving what I want to do.

In one case for instance, I actually used a line of black timed text (all squares/special chars) to suppress an unsuitable line of text in a trailer. Technically, I created a subtitled trailer VF with the only intention to mask a single line of text with the subtitles over a black background. These things usually only work under very constrained conditions. Would the background have been anything else than full black, it wouldn't have worked.
I certainly wouldn't have trial'd-and-error'd to match subtitle text color with a special background - also because, subtitle color rendering on various DCI machines is not 100% precisely defined, and it may differ between DCP-o-matic preview and the actual projector.

Yes, of course I have various video editors on my personal machines, but these I usually do not have with me when I'm working at the cinema on playlists. I usually don't consider these modifications as a real necessity, it's more a fun thing, and it aids also in learning, trying out and debugging DCP-o-matic.

Long story short - be careful with what you do with VFs.

It is easy to replace e.g. a single frame in a MXF by loading that MXF two times (right-click-repeat), trimming both before and after the frame to be replaced, insert the new frame and recreating it. But then, you'd better recreate a new, fully autonomous DCP/MXF to be used in the final DCP.
This special operation to replace e.g. a single flash frame will probably work as a VF on all servers. But I wouldn't risc much more than that. Commercially mastered mainstream DCPs usually come in reels, and the general approach then would be to replace a full reel.

- Carsten
binba
Posts: 11
Joined: Thu Jul 04, 2019 3:56 am

Re: Splicing a DCP (insert edit)

Post by binba »

I agree that it's best to avoid VF's - what I meant is to have DOM do an insert/replace edit and create a complete, autonomous DCP without VF's.

For example:
  1. You have an already-authored DCP of 1,000 frames, and new picture for frames 500-600 (say, in a ProRes MOV) which matches the original settings.
  2. You reopen the DOM project, and instruct DOM to replace frames 500-600 with that MOV.
  3. DOM extracts J2K frames 1-499 and 601-1000 from the existing DCP MXF; encodes the new MOV as frames 500-600; copies the audio MXF as is; and packs it all together in a new, complete, autonomous DCP with a CPL identical to the original.
It may even be possible to modify the DCP "in situ", destructively, if desired. I know it's technically possible and allowable to modify an MXF file (see this cool tool and page 11 here - I don't know if it's allowable for DCI MXF's.
Carsten
Posts: 2648
Joined: Tue Apr 15, 2014 9:11 pm
Location: Germany

Re: Splicing a DCP (insert edit)

Post by Carsten »

What you describe is perfectly possible. Add both content, edit trimming for both with frame accuracy, recreate DCP - no problem to mix a ProRes with preexisting J2K footage. DCP-o-matic will only compress the Prores Footage, and reuse the J2K frames.

- Carsten
IoannisSyrogiannis
Posts: 128
Joined: Mon Nov 13, 2017 8:40 pm

Re: Splicing a DCP (insert edit)

Post by IoannisSyrogiannis »

...DCP with a CPL identical to the original.
That I didn't quite understood...
Identical would mean having the same elements and UUID also, but that can not be the case.
Carsten
Posts: 2648
Joined: Tue Apr 15, 2014 9:11 pm
Location: Germany

Re: Splicing a DCP (insert edit)

Post by Carsten »

That could indeed become a problem. But is probably not needed in a strict. However, by 'just' editing the CPL and in/out points, all the remaining metadata would stay the same, including all UUIDs. And then, depending on the distribution situation, we may end up with two 'different' DCPs, but with the same CPL UUID - and that is not a good idea to do. So, however the new/correct DCP is actually made, it would be wise to create a new UUID/CPL - no matter wether it's a new OV or a VF based on an OV that has to be corrected.

- Carsten
Post Reply