Seamless Video Cues

[david...@sxsevents.co.uk]

Hey All, 

This has likely been covered before but I can't find it with a search around the documentation. 

How can you get videos in a stack to seamlessly join, is there a cue I can put in to prepare the video like in watchout?

If I have my looping video as one cue and set to loop under time and loops. Seamless looping no problem.

I've tried a couple of different things too:

If I create 2 cues and have it auto continue, I get a hang as it moves on to next video. 

If I create 2 cues and use an pre-wait I get a hang as it moves on to next video. 

Thanks in advance for your help!

[Christopher Ashworth]

Hi David,

The design of how cues work in QLab doesn't actually include a guarantee of seamless output when moving between two separate cues. (This is true for both audio and video cues.) the reason for this is to allow it to guarantee that cues that start at the same time will be sample-accurate synced together. Because QLab does not have guarantees (in the general case) about when individual cues might start, it is a case where guaranteeing one thing prevents guaranteeing the other.

Approaches to avoid a frame of black between cues include: pause a video and restart it, cross fade between videos, devamp a looping video... possibly others I'm not thinking of

(mobile)

[Rich Walsh]

An obvious question perhaps, but are the cues loaded? You could also add a tiny negative post wait and auto-continue to make sure the next cue starts just before the current one ends.

Rich

[david...@sxsevents.co.uk]

Thanks Chris,

I'm not actually getting a black frame just a hang. Maybe we could do a cross fade, naturally would have to be a consideration in production to have a second or so of pre-roll on all the clips. 

[david...@sxsevents.co.uk]

Rich,

Thanks for the advice, I think by using the second methodology I posted above with the prewait they would both be loaded?

So I'm triggering both clips at the same time, then using a pre-wait the length of the first clip on the second. Would that be the correct approach?

Thanks

David

[Rich Walsh]

Either of your ways of constructing a sequence will load the sequence if you have set the cues to auto-load – which, for reasons I do not understand at all, is not the default for new workspaces (I am yet to encounter a scenario where I don’t want my cues to GO when I fire them, but at some arbitrary and unpredictable time later…).

You could do what you say, or you could read what I wrote and do that: set a _negative_ post wait (available in v4) on the first cue and set it to auto-continue into the second cue. This will fire the second cue just before the first cue ends, which your version will not.

Rich

[Sam Kusnetz]

On March 13, 2017 at 7:54:31 AM, Rich Walsh (rich...@mac.com) wrote:

you have set the cues to auto-load – which, for reasons I do not understand at all, is not the default for new workspaces (I am yet to encounter a scenario where I don’t want my cues to GO when I fire them, but at some arbitrary and unpredictable time later…).

Rich

The reason auto-loading was turned off by default in QLab 3 was this combination of facts:

1. Playing a single non-loaded cue in QLab 3 (and QLab 4) is dramatically faster than in QLab 2.

2. SSDs and faster CPUs mean the speed difference between playing a cue that is loaded and one that is not loaded is shrunk even more… it’s basically impossible to even measure the difference on a new Mac when you’re playing a single cue, and difficult to measure even with small cue sequences.

If a very complex cue is loaded, and the act of loading it causes enough strain on the CPU and disk, then cues which are playing at that moment can be caused to stutter. Since QLab has no way to know, by itself, what the right moment is for loading a cue, we have selected the default behavior for QLab to be “make fewer assumptions.”

Since the vary majority of QLab users do not push their Macs to the limit, most people never notice the difference between loading and not loading. Those who do can selectively  auto-load, or manually load, their cues in a manner that best suits their show. 

Best

Sam

—

Sam Kusnetz | Figure 53

s...@figure53.com

[Rich Walsh]

Interesting… For me the workhorse for audio QLab is the Mac mini, which does not ship with SSDs even now. I’ve never even really been that bothered about 7,200rpm drives except when using Pro Tools – and it’s not the drive speed that causes me issues on this ageing MBP. Maybe once every few shows I’d have to preload a sequence so it could cope with a series of fast GOs, but I’ve never been caught out by the old auto-load behaviour on medium spec machines with 5,400rpm drives. On one show we were running Live at the same time on the same Mac mini.

I do notice that cues are late if I don’t enable auto-load, so I suppose my setup must be slow by current standards – being a year or two older than QLab 3.

Maybe it’s a video thing?

Rich