2K 24fps Audio/Video Sync Drift

[Ryan Gallagher]

Hello,

I recently had a festival DCP come to my booth created with DCP-o-matic that exhibited severe desync (and got worse the further into the DCP you played it). They had to pivot and screen the prores version from a laptop after tech check.

I've only ever made DCPs myself from self-contained audio/video files for prerolls/transitional, haven't had to tackle features in any seriousness. I believe the source framerate was 23.97fps 4K, dcp was produced as 24fps 2K. By the end of the 1:48:07 feature, I'm counting about 14s of audio delay, which is also present when viewed with DOM player.

I do actually have access to their DOM project files, which I'm downloading now to investigate. The festival contracted someone to convert to DCPs for them, what mis-step could they have taken to cause this audio sync issue? I expect they might have been handed a 4K Prores file as the media source. My impression was DOM was pretty smart about framerates and audio conforming stuff.

[Carsten]

Which version of DCP-o-matic was used to create the DCP?

Carl took considerable effort to cure various sync problems. However, it seems the 'better' approach to sync audio and video sometimes seemed to make things worse for some files. It seems to be tricky, because some file formats do not just establish a static timebase for the whole file (like 'all frames are 23.97'), but every frame may contain an individual time stamp, and that may cause a heck of problems when syncing them to a static timeline and accompanying audio frames.
Some smartphones create videos with variable frame rates in order so save storage space, even when setup as '24fps'.

[IoannisSyrogiannis]

Carsten beat me to it. No need to read my rambling. Unless you have time to waste.

DCP-o-matic is not smarter than dumber than the following:
If you have interleaved audio channels muxed in the video, the audio is speeding up or down depending to the framerate conversion.
It resamples, so a 48KHz will be at the DCP, but it doesn't pitch correct, for instance.
There were issues in previous versions with framerate changes. I clue might be on the version of DCP-o-matic that made the DCP.

Problems could have risen from variable framerate, wrong settings on separate or discreet audio channels. The more one knows about the original file(s) and the exact steps followed, the better guess one could make.

The question for me is less troubleshooting the one between the number of the DCPs made and more evaluating the method. If you were able to check on DCP-o-matic Player and find that delay, what was wrong with the contractor's Player or QC?
My guess is that they either were too time-pressed to check, or(/and) they didn't plan to from the beginning.

I had a few stories to tell about receiving material paid and made for with DCP-o-matic, EasyDCP, QubeMaster, CineAsset, Dolby SCC, Clipster that had serious problems. The most dominant flaw was the lack of quality control from the author. I used to get angry, mostly because I was jealous of people that used equipment of tens of thousands <currency here> and created crap, while saying "no, the DCP is fine, it played on other venues/festivals with no problems. It must be your equipment/download/feng-sui/karma/horoscope".
I am somewhat better now, thank you.

[carl]

An error of 14s is longer than I would expect for a 23.97/24fps mismatch over that length of film, so I would suspect something more serious is going on.

If they take any file (no matter what the frame rate) that plays correctly in other players (e.g. VLC), and get an out-of-sync result I would consider it a bug in DCP-o-matic that we should definitely try to fix.

I agree that it would be nice if people checked for this kind of thing as a basic QC step (especially since such a check is not trivial to do automatically), but it shouldn't happen in the first place unless they do something wrong.

It would be interesting to see the metadata.xml and the log files as a first step, however. Perhaps something else is going on that I haven't thought of.

[Ryan Gallagher]

Cheers. I don't have the master so obviously my DCP-o-matic complains. But it does appear it was a .mov 4k master, single file, and interface confirms 23.9760fps of the content.

Where in the project folder could I determine what DOM version the author was using? I'm linking the "log" file, but it is named differently than how I think current versions handle them?

Screenshots of Project UI using my 2.18.17
https://drive.google.com/drive/u/0/fold ... hu2MVKMSRu

"log" file as log.txt:
https://drive.google.com/file/d/1yKe5Di ... sp=sharing

[Ryan Gallagher]

I've added some of the other project files to the shared directory, metadata.xml, metadata38.xml, and a zip of the file within info folder.

https://drive.google.com/drive/folders/ ... sp=sharing

I have the DCP and video folder content, but it's an indy feature and hesitate unless devs ask for it to troubleshoot.

[carl]

Thanks for the log. There are a lot of errors from FFmpeg when it is reading the ProRes file, which probably explain the sync problems.

Unfortunately DCP-o-matic does not do a great job of pointing such errors out to the user...

This could be some corruption in the source, or a limitation/bug in FFmpeg, or something I'm doing wrong in DCP-o-matic.

It would be difficult to fix without a copy of the original Prores file, unfortunately. If you want to put me in touch with whoever has that, feel free: carl@dcpomatic.com

[Ryan Gallagher]

Cool, I do have the contractor's information. I did find the DOM version though in the ASSETMAP
DCP-o-matic 2.16.91 e96f917d51

Also no guarantees that master didn't have sync problem too, cause I never saw that file in my booth, they had other renders they handed me for projection as ProRes, but those were fine.