Black Frames between clips in DCP (Xmas Bug?)

[Ryan Gallagher]

Here something I thought would be simple, but may have found a bug or limitation in DOM thanks to a very holiday request:

Asked to loop a animated title card with snow for projection on the main curtain during walkin. In DCP speak, that means stack a bunch of them to make a reasonable length DCP, and then stack those DCPs in the SPL of the server equal to the needed runtime.

File definitely has no black frames, and OBS loops it seamlessly as intended. VLC will freeze a bit on the repeat point (due to reopening the file it seems). But DCP played via Doremi DCP2K4 and DOM Player both exhibit a black frame glitch between each clip in the DCP. Is this an expected limitation? Or something that can perhaps be fixed?

The 30fps file I was asked to loop is here:
https://drive.google.com/file/d/1WPZcRu ... sp=sharing

made 30fps Flat 185 DCP. An example DCP with 3 of the source files repeated is here:
https://drive.google.com/file/d/1PX3G1Q ... sp=sharing

I was definitely hoping this was easy to do in DOM, but it seems we need to ask for longer source animation files (pre-looped), or switch to ALT inputs on the projector. Would a 24fps source and DCP fare any better?

PS - I know there is a visible snow "shift" at the repeat point, our programming team apparently did not use a very loopable snow clip. I have better snow clips I can give them but the black frame every 35s was the real problem on the first DCP attempt.

DOM v2.16.98 on Windows 10 PC.
Thanks!

[Ryan Gallagher]

For grins, I tried re-exporting the video in DOM back to an mp4. The black frame(s) glitch carried through to the export as well.

Visible at the 35s repeat point in this file twice:
https://drive.google.com/file/d/1fhux9i ... sp=sharing

I suppose my next thing to try would be to ditch the MP4 sources and ask for pro-res?

[IoannisSyrogiannis]

[...]
I was definitely hoping this was easy to do in DOM, but it seems we need to ask for longer source animation files (pre-looped), or switch to ALT inputs on the projector. Would a 24fps source and DCP fare any better?
[...]

In regards to that, if the video has no audio, you can just force the framerate on DCP-o-matic. (On every clip, but you can do that on one and repeat.)
If it has audio, on the other hand, it will turn from Doris Day to... Bing Crosby.

Edit: I wouldn't go for 30fps on anything DCP. Some cinema servers were known to introduce artifacts on frame-rate changes. I do understand that this is not what you describe here, since it is mid-file, but I would rather export 24, 25, or 23,974 (and let DCP-o-matic turn it to 24).

[StephW999]

this is due to the 29.97 conversion at 30 frames per second ;
this adds an unintended image. (anyway I guess)
To help you quickly , here is an additional package to remove this black image:
https://fromsmash.com/OuzunahVFl-ct

[Ryan Gallagher]

Thanks for the tip it was the 29.97 framerate of the source. No audio so not worried about that. I swear I looked at the file info but I must have rounded it up in my head to 30fps. It seems it was just a coincidence that our initial black frame fell so close to the 35s clip point, and so I didn't even consider that the frame rate might be the culprit.

Two methods that fix it from my testing (other than asking for a better FPS export and codec from programming dept.):
- Transcode from the 29.97 h.264 to a constant 24fps outside DOM and then make a 24fps DCP
- Transcode from the 29.97 h.264 to a constant 30fps outside DOM and then make a 30fps DCP

Because this snow file is a worst case example for fps transcoded motion stuttering, the 30fps looks the best to me, but only cause our projector can handle it.

Resulting 30fps DCP looped 3 times,
https://drive.google.com/file/d/1e-anBi ... sp=sharing

DOM also exports h.264 versions now without the glitch, but yet to test on screen:
https://drive.google.com/file/d/1htZbWA ... sp=sharing

But for what it's worth, black frame insertion for 29.97 sources still feels buggy to me, wouldn't the better behavior be to duplicate a frame (perhaps that is not an industry convention, though I did not try transcoding outside of DOM to anything other than h.264). Given audio might drift or be at an unintended speed, perhaps the black frame draws more attention to the issue so you can fix it?

Aside. I accidentally made a 24 variable fps file in handbrake initially for testing. Windows must report the peak fps, and reported 22ish. DOM handled it but left a huge 2ish seconds of black on an expected interval in the DCP. Is DOM even intended to handle variable frame rate h.264s? If not a louder warning in the UI might be justified.

[Ryan Gallagher]

Not to confuse the issue when it seems we found the cause.

But we have another 29.97 h264 file we have used this series, and it exhibits zero evidence of the black frame insertion when played as a DCP.

I'm stacking two in a DCP now just to see if it is the repeating clips that contributes to the issue. But would have thought we'd see the problem with it too being that it is close to 2 min long.

Source File
https://drive.google.com/file/d/1fDWDDY ... sp=sharing

EDIT: That file also causes additional black frames at the end of the clip, which DO appear in the DOM editor when you look for them. But would only be visible on screen if 2 or more copies are added to a DCP back to back.

[IoannisSyrogiannis]

Nice that you had it worked out, but I am curious. If you had it imported to DCP-o-matic and then slowed down to 24 fps (yes, the fall of the snowflakes would have been slower as well), would there still be those black frames?
Did you try and failed, or just didn't want to mess with speed?

[Ryan Gallagher]

Nice that you had it worked out, but I am curious. If you had it imported to DCP-o-matic and then slowed down to 24 fps (yes, the fall of the snowflakes would have been slower as well), would there still be those black frames?
Did you try and failed, or just didn't want to mess with speed?

Trying that now. Correct me if I'm wrong, but does DCPoMatic actually transcode for frame rate conversions? Or just speed up or slow down the playback? I'd always assumed transcode but I haven't had to do it much so might have been wrongly thinking there.

Also. OMG. So their 2nd clip they provided for the next film actually had a very obvious block of black frames at the end in the original (EDIT: not true, I was just seeing them in the DOM editor). In doing this next test I caught that they existed in the White Christmas one too (EDIT: in the DOM editor). *face palm* 8 black frames. Trimming those off should solve all my woes.

[Ryan Gallagher]

Oooof. I'm just now catching the black frames in the DOM editor when dropping those clips in. I was not looking close enough at the end of each clip before just expecting it to work, all three 29.97 h264 clips I'm working with cause them to appear in the editor too.

I cannot find evidence of them in other players going frame by frame, but VLC is not the best tool. Perhaps they exist in the source. Trimming them off in DOM appears to be equally valid solution.

But I'm still confused as to why DOM would be adding them (if it's adding them). If it was due to 29.97 -> 30 in DOM I would expect the number of added black frames to vary depending on the clip length. But i'm seeing 9 frames in both cases.

PS the result of making a 24fps and 30fps DCP version starting from the original 29.97 source, but trimming the black frames, works fine and only playback speed seems affected, motion is not impacted by rate change, so I guess that answers my question earlier. DOM it seems does not convert between framerates, but simply places them in sequence and defines the DCP frame rate. Good to know.

[Ryan Gallagher]

For clarity, I dropped both original 29.97 clips into premiere and see no black frames when frame advancing or going to the clip out points. So it's definitely DOM appending them, but at least now I know to look for them in the editor and can trim them if needed.