[QLab] video stutter work-arounds?

2,492 views
Skip to first unread message

Michael Sider

unread,
Sep 3, 2010, 1:15:29 AM9/3/10
to ql...@lists.figure53.com
Hi All,

I'm running video through Qlab and am having stutter issues at the top of clips. I resolved the issue initially by converting from the original video format of prores 422 to h264, but then needed to add 6 discrete channels of audio to the clips in place of the original 2 stereo channels (re-outputted the video from Final Cut with 6 channels attached and then switched them in to replace the stereo video clips in qlab). After adding the 6 audio channels, started having stutter problems again.

Found a possible work around by separating audio from video (outputting the 6 channel audio as an aiff, and the video as quicktime video without audio) and loading the audio cue into Qlab followed by the matching video cue (with no attached audio). Playback has them synched. This works great, am even able to switch back to using prores 422 codec. 

Do you follow me?

As this work-around will very labour intensive to rebuild (dealing with roughly 100 cues), any other clever (less labour intensive) work-arounds for video stutter?

my specs:
Mac Pro quad core 2.66 Ghz processors, 6 gb ram (purchased 6 months ago), sending from Qlab through two NVIDIA GeForce GT 120 graphics cards to two image blended Panasonic DW6300 projectors, each video output is 1600x800, started at prores 422 (HQ), more recently h264 full quality video codec.

Thank you for your time!

Michael

Christopher Ashworth

unread,
Sep 3, 2010, 7:21:14 AM9/3/10
to Discussion and support for QLab users.
Hi Michael,

I suppose one thing to check is the usual series of "are subsequent cues preloaded" checks. The idea being that the stutters may be due to lots of extra loading for subsequent clips when you just want the current cues to run.

Ah, video. If only there were ever an easy way with video.

-C

On Sep 3, 2010, at 1:15 AM, Michael Sider wrote:

> Hi All,
>
> I'm running video through Qlab and am having stutter issues at the top of clips. I resolved the issue initially by converting from the original video format of prores 422 to h264, but then needed to add 6 discrete channels of audio to the clips in place of the original 2 stereo channels (re-outputted the video from Final Cut with 6 channels attached and then switched them in to replace the stereo video clips in qlab). After adding the 6 audio channels, started having stutter problems again.
>
> Found a possible work around by separating audio from video (outputting the 6 channel audio as an aiff, and the video as quicktime video without audio) and loading the audio cue into Qlab followed by the matching video cue (with no attached audio). Playback has them synched. This works great, am even able to switch back to using prores 422 codec.
>
> Do you follow me?
>
> As this work-around will very labour intensive to rebuild (dealing with roughly 100 cues), any other clever (less labour intensive) work-arounds for video stutter?

________________________________________________________
WHEN REPLYING, PLEASE QUOTE ONLY WHAT YOU NEED. Thanks!
Change your preferences or unsubscribe here:
http://lists.figure53.com/listinfo.cgi/qlab-figure53.com

sam kusnetz

unread,
Sep 3, 2010, 12:22:27 PM9/3/10
to ql...@lists.figure53.com
> my specs:
> Mac Pro quad core 2.66 Ghz processors, 6 gb ram (purchased 6 months ago),
> sending from Qlab through two NVIDIA GeForce GT 120 graphics cards to two
> image blended Panasonic DW6300 projectors, each video output is 1600x800,
> started at prores 422 (HQ), more recently h264 full quality video codec.

are you, by any chance, running a video cue via custom geometry that is being sent to more than one video output?

if you are, try limiting your video cues to one output only, and using multiple copies of you video running simultaneously instead of stretching one cue over two outputs to get what you need.

does that make sense?

the reason for this is that video which hits more that one output needs to be rendered in the CPU first before being sent to the GPUs. i bet that's your problem.

cheers
sam

Reply all
Reply to author
Forward
0 new messages