DCP-o-matic

Hi again, guys!

I've noticed that certain video source files seem to trigger weird behaviour in D-o-m: the audio is thrown off sync when exporting to file – but not when creating a DCP from the same file, from the same project, with the same settings.

Case:

• I've received a short film as an mp4 (h.264/AAC) file
• I create a new project in D-o-m and import the mp4
• I trim it to 30 seconds (just to make this test run quicker; all other settings remain at defaults)
• I create a DCP: audio sync matches the source file exactly
• I export to a ProRes file: audio is 5 frames late

I've experienced this with several mp4 and ProRes files from various sources. I can't seem to find anything out of the ordinary in these files, but the problem does disappear if I put them through a simple "ffmpeg -i infile.mp4 -c copy outfile.mp4".

The files are copyrighted material, but I can PM a download link on request.

We had a few audio sync issues recently because of weird audio stream properties (duplicate presentation timestamps).

viewtopic.php?f=2&t=1439&p=6250&hilit=timestamp#p6250

It went back and forth, and maybe some of these issues are solved for the DCP, but not the export. Personally I never had audio sync issues, it is weird that some audio files use these strange capabilities. Wondering wether this could actually be a sick copy protection method.

You could try to reimport the created DCP into DCP-o-matic and export this to Prores. Of course your FFMPEG in-out copy is the better way.

OK, so it was a known issue – thanks! I just run a quick test on 2.15.135, and it seems to be fixed all right.

Carsten wrote: ↑Tue Mar 16, 2021 10:49 pmYou could try to reimport the created DCP into DCP-o-matic and export this to Prores.

This wouldn't have worked for me in this case, as it will introduce a color shift. I've always assumed it to be a more-or-less inevitable side effect of RGB –> YUV –> RGB conversion, so I haven't filed a bug report

Which version did you use that created the sync issue?


Carl - was the fix for the duplicate presentation timestamps also backported to 2.14.x? I guess so?!

That was 2.14.47 (Ubuntu 20.04, but I'm pretty sure I've seen the same issue in the Mac version).