Smoke Break... Render incorrectly references media below it in some cases

[cyphen]

So I've taken to lovingly calling these little undocumented features "Smoke Breaks" ...
 🙂

This is an interesting one. Here's the dillio...

I built a vertical timeline as shown in the image. No connect effects or action or anything. Top Layer (L7) is a graphic with alpha. L6 below it is a disclaimer (this and L7 are where viewing issues occur) The disclaimer is a big graphic, and all but 2 lines are cut out using a gmask and then displaced using a 2d Transform.

L5 is another lower third graphic with alpha. L4 is simply black video transformed down to create a black bar at the bottom of the screen. L3 is an after effects graphic comp with alpha. L2 and L1 are full frame video tracks. I originally was using L1 as a guide track and just never bothered to remove it, since this wasn't a real project.

Now, here's what happens (reference the attached image for clarity...). When the clip on L6 (2 line disc with 2d transform and gmask) is unrendered, everything displays correctly. However... when i RENDER that clip, the background layer has a visible jump in it when moving from the end of that clip on L6 to the beginning of the next clip.

Here's why (or at least what's happening)... The edit on L2 ends prior to the clip on L6 ending. At the point where the clip on L2 ends, the rendered image on L6 displays video AS IF the video from the clip on L2 continued, rather than having a cut point and switching to the next clip (named BinaryCodeBG). Hopefully that's not too

confusing - it's rendering as if the clip on L2 was extended.

Now here's where it gets interesting. If the clips below L5 are rendered, it renders correctly. If an add edit (razor/other terminology) is performed on L4 at the point where it displays incorrectly, then it renders correctly.

So what i think is happening is either a shortcut logic error, or a weird issue with gmask or something. I think it's, for some reason, saying in the render process, hey, there's a continuous clip a couple layers below. Let's take grab the media from the clips below it and assume that they continue throughout the duration of the render. I don't know this for sure, but it's something to be a little wary of.

Again... it displays fine unrendered. It renders incorrectly at the cut point on L2 in the upper attached graphic, as if the clip were extended on L2 as shown in the lower timeline on the graphic.

Weird eh? The issue has been logged, and they're looking into it at command headquarters... but i thought i'd mention it to see if anyone else had experienced something similar, or could possibly shed any light on why something like this might happen. All media was cached to DPX. Again... unrendered, fine. Rendered, not fine. Just another reason we editors need to keep our eyes peeled ALL the time!! 🙂

~Scott
End of line.

[ManChicken · Accepted solution]

This is a bug I've run into on Flame as well, and submitted it with an archive.  You can mention to support my case number 00561880 for reference so they know it's not isolated.

As far as I know it's not related to your GMask, it's just some sort of logic error when the rendering process evaluates/optimizes its render list, and it gets confused by overlapping segments of clips and freezes stacked up (my situation is similar to yours, I have a base edit on V1 and various layers of motion graphics and stills for lower 3rds, disclaimers, etc. on multiple tracks over top.)

That said, to work around, clear your bogus caches, then turn on 'Cache On Playback' and 'Play All Frames' and then play through your timeline/affected sections (you might mute your audio tracks because it's annoying) and that should give you the correct result.

[jaseo]

Another workaround might be to go to prefs/timeline/rendering, change track based to frame based rendering.

cheers

Jason

[cyphen]

Thanks Bob! I'll let them know. Good to know about the "workaround" - or i guess, prophylactic measure is a better description. Anyway, yeah, that's exactly what it seemed like to me... an optimization method that incorrectly makes some assumptions about the media required for the render. Or some similar bug that has a similar effect, as opposed to deliberate code.

Hopefully they get that sorted out in the next release. It would be really unfortunate to always have to cache everything... 😞

[cyphen]

Also - thanks Jason. I had actually tried switching between those modes with no effect. Still had the issue. Thanks for the idea, though!

[ManChicken]

---

@cyphen wrote:

Hopefully they get that sorted out in the next release. It would be really unfortunate to always have to cache everything... 😞

---

Well, if you have to render your sequence, you have to render it... this is just a different way to go about it.

[cyphen]

Oh - gotcha. I thought it would render every layer separately. I'm relatively new to smoke... transferring from 14 years of DS, so I'm still getting used to how things work in smoke... Anyway, i verified that this actually does work, so thanks again!

Scott

[ManChicken]

Oh, no..  It literally will just save rendered frames to the framestore as it plays (or even as you scrub through frames on the timeline yourself.)

I'm an ex-DSer as well -- it's a bit like processing in "Minimal" mode.  The timeline has to render any un-rendered frame to show you the result (whether it's a single clip or a stack of tracks) anyway, and 'Cache on Playback' saves it to the framestore rather than just throwing it away.  It's a lot like After Effect's disk cache (blue frames.)