DCP-o-matic (currently) never drops frames in that sense; perhaps it should, sometimes. All it does is try to skip or repeat frames to get closer to the required rate, and then it gives up and runs the content too fast or too slow, as required.

I don't think it makes much sense for external tool authors to reimplement DCP-o-matic's logic; apart from anything else, it may change.

Your solutions based on writing XML to the metadata.xml look OK, though it seems a little bit of a shame to "clutter" that file with stuff that DoM can calculate by itself.

An alternative might be some API where you could ask DoM to tell you this stuff; for example, what if you could do

$ dcpomatic_info --total-dcp-length my_great_dom_project
dcp_length 01:30:44

Would that solve your problem?

Two things:

Calculating end position of content

Ah ha! Yes, you're right an addition to the CLI API would solve this problem better. Please see 0001702 for a suggestion.

Control of how DCP-o-matic does frame rate conversion

I think it would be useful in some cases for the user to have control over how DCP-o-matic does frame rate conversion.

For example, if I have a 60fps file and want to make a 24fps DCP, at present DCP-o-matic skips every 2nd frame to get it to 30fps and then slows what remains down to 24fps. There's no way to change that.

The user might prefer to skip more frames, in order to go from 60fps -> 24fps without changing the running time of the film. i.e. skip 3 frames out of every 5.

Another example: 18fps source -> 24fps DCP. User might want to repeat frames to get to desired frame rate, rather than speed up the film 33%.

An extra control "Conform frame rate" would satisfy both cases. Frames would be dropped/repeated to get to the Conform Frame Rate and then speeded up/down to get to the Output Frame Rate.

Personally, I would prefer such a control to be able to be set per piece of content, rather than for the DCP overall. A good place for it could be at the very bottom of the Timing tab.

What do you think?

I am not very experienced with the visual effects of dropping frames, but I was always under the impression that dropping e.g. 3 out of 5 looked so bad that nobody would want to do it! :)

If it's a useful option we can certainly support it. It's a bit of a worry to add new and potentially scary GUI controls but things get scary enough by the bottom of the timing tab that it would probably be fine.

Well, yes, generally you wouldn't want to drop frames unevenly. But sometimes, if you have a 30fps film and the projector it needs to play on only supports 24fps, you don't have much choice.

Motion-compensating frame rate conversion (an algorithm that "intelligently" constructs new frames by detecting differences between frames before and after) can be a better option, but it also can produce nasty artefacts. It doesn't work well with some types of footage.

Having said all this... Personally, I don't feel there's a strong need for this feature. For me at least, occasions where it would come in useful are pretty rare, so it's not a big deal in these cases to convert the source to desired frame rate in other software prior to putting it into DCP-o-matic.

If it was easy to implement, it might be worthwhile, but otherwise maybe wait until someone else brings it up as something they have a real need for.

My main objective in all this was to find a way to correctly calculate the end position of content, which is now going to be covered by 0001702.