[QLab] recommended minimum hardware for video
Zach Rosing
Been using QLab for about a year now and I absolutely love it. Because none of the theatres in town have Macs, I bought a used Mac Mini to run the software for the projects I design for, so that I'm not giving them my laptop. But I'm finding it has trouble when it comes to video. In general it runs everything just fine, but often when starting a video clip, the first half second will get cut off (sound and/or video) or otherwise stutter. I have load cues for all my files, so everything is in memory ready to play. Sometimes it'll be perfectly fine, but often if there hasn't been any activity for a few minutes, that's when I have problems. And of course, it isn't reliable.
My machine is the Early 2009 revision (Macmini3,1). It's an Intel Core 2 Duo 2Ghz. I believe its been upgraded to 4gb of ram (it's not in front of me at this moment). NVIDIA GeForce 9400M. I know this isn't an amazing machine, but I think it should be more than sufficient to do what's being asked. I'm pretty Mac savvy and have tweaked every setting I can find, and disabled anything that isn't necessary--nothing is going to sleep, there are not unnecessary programs running, etc etc. For my current project, my video clips are 1024x768 sized MOV files either using Animation or H.264. I've even had problems like this with simple audio clips--during a production of The Producers, with gunshots timed to the beat, I had to add a half dozen blank audio cues just to hope to get the computer to fire the real ones the split second I hit go.
Shouldn't this machine be able to handle this? If not, what are the minimum suggested specs for QLab? Does anyone have suggestions on what could be causing this lag? Are there ideal and not ideal codecs for video clips?
Zach
________________________________________________________
WHEN REPLYING, PLEASE QUOTE ONLY WHAT YOU NEED. Thanks!
Change your preferences or unsubscribe here:
http://lists.figure53.com/listinfo.cgi/qlab-figure53.com
Follow Figure 53 on Twitter here: http://twitter.com/Figure53
Ted Pallas
Ted Pallas
Live Media Design
Sandwich Construction Consultant
cell - 516 286 9661
Pardon the typos, sent from my Casio SK-1
Christopher Ashworth
What's the speed of the hard drive on the Mini? A 7200 is what I'd consider a minimum requirement for video work.
In general Minis aren't ideal video machines because they don't have dedicated video RAM, and steal RAM from the main system instead.
PhotoJPG as a codec is also a good thing to try, as long as the hard drive is 7200 or SSD. It will be easier on the CPU, although it'll pull more data from the disk at the first step.
Zach Rosing
Like I say, it's not any problem keeping up with the clips once they start, or them playing smoothly--it's only the lag at the very beginning of a clip, and only when the machine has been sitting idle for more than a few minutes.
As to my original question though, do you guys have any recommended minimum specs for a machine cueing video? Other than a 7200 rpm drive? What machine do most people run QLab with?
Christopher Ashworth
On Jun 1, 2011, at 5:36 PM, Zach Rosing wrote:
> This Mac Mini is a 5400, and that was one of the things I was considering--if 7200 vs 5400 would make that big of a difference. My MacBook Pro has a 5400 drive and I haven't had these issues using it.
>
> Like I say, it's not any problem keeping up with the clips once they start, or them playing smoothly--it's only the lag at the very beginning of a clip, and only when the machine has been sitting idle for more than a few minutes.
Is it certain that the drive is not going to sleep?
Another thing to check: is there a heavy sequence of cues being preloaded AFTER the clip that is stuttering? It might help to preload the next sequence too....
Best,
Chris
Matthew Haber
Matthew Haber
Lighting & Projection Design
Isadora, Quartz and Watchout Programming
www.matthewhaber.com
617-435-9257
On Jun 1, 2011, at 5:36 PM, Zach Rosing wrote:
Paul Gotch
> In general Minis aren't ideal video machines because they don't have
> dedicated video RAM, and steal RAM from the main system instead.
The situation is complicated.
It doesn't really matter much that the IGP shares with main memory as
the memory system is designed to cope with it.
It's no worse than what happens in a Core i5/i7 based MacBook Pro or
iMac even with discrete graphics. The way the graphics switching
between the IGP and the discrete graphics works means that the DVI
output is always being done by the IGP and there is always a copy of
the frame buffer in main memory. If the discrete graphics is being used
then it renders into it's own memory then this is DMAed into the
framebuffer used by the IGP before being output.
The only way to avoid the multiple copies is by using a Mac Pro.
Video is extremely tricky to get right, you have to balance:
- The required compressed bit rate you need to stream from your mass
storage device. Using lightly compressed codecs such as PhotoJPEG or
ProRes makes this part extremely important. Using heavily compressed
codecs such as H.264 makes it less important.
- The required processing power to decode the video. In general less
compression means a lower overhead. However it depends on if hardware
assistance is available and being used to decode the video. For
example some graphics chips can accelerate H.264 decoding under some
circumstances.
I think the basic problem with video in QLab is it allows you to do too
much and use too many different codecs. Dedicated VPUs and video
servers which have come from the lighting world, such as Hippotizer and MA
VPU, have:
- Fixed known hardware
- Cross code everything to a known 'native' format
- Place a limit on the number of concurrent streams
- Place a limit on the number of concurrent outputs (usually
physically)
-p
--
Paul Gotch
--------------------------------------------------------------------
Keith Smith
On 2 Jun 2011, at 01:31, Paul Gotch wrote:
> I think the basic problem with video in QLab is it allows you to do too
> much and use too many different codecs.
I disagree. I like the fact that QLab is Quicktime based. I like having the flexibility to tune my video to the codec(s), bitrate, colorspace, field ordering, frame rate and frame size that will work best with whatever hardware I will be using for a given event.
Yes, video is complex and it has a steep learning curve if you want to be good at it - but then what doesn't?
In short: I'm all for making things simple, but for goodness sake don't take my advanced options away from me!
> Dedicated VPUs and video
> servers which have come from the lighting world, such as Hippotizer and MA
> VPU, have:
>
> - Fixed known hardware
> - Cross code everything to a known 'native' format
> - Place a limit on the number of concurrent streams
> - Place a limit on the number of concurrent outputs (usually
> physically)
>
Actually, this is good advice for projects generally. For a given project/event determine what the above elements are and then make all media conform to them.
Regards,
Keith.
Rich Walsh
> I've even had problems like this with simple audio clips--during a production of The Producers, with gunshots timed to the beat, I had to add a half dozen blank audio cues just to hope to get the computer to fire the real ones the split second I hit go.
I've been pondering that line and wondered if Guaranteed Sync was on?
I don't think there's an equivalent in Video Cues, but your Mac mini
should easily be able to handle audio - I built half-a-dozen systems
based on the same model, I think.
Have you checked the Console for any messages from QLab as to what is
going on? Also, if you are using an external audio interface try
running using the built-in audio instead to rule out any third party
drivers.
As Chris has observed, loading is something that can cause delays.
Generally you don't need to put Load Cues in yourself; I only put them
in if I'm going to need to fire two cues in quick succession: I'll
have the cue before the first cue load the second cue once it has
finished everything else it's meant to do. I've needed such Load Cues
in about 1% of the sequences I've programmed in the last 2 years. Try
disarming all your Load Cues (and certainly don't try to load
everything at the top of the show) and see if that helps.
Rich
*
>
>> I've even had problems like this with simple audio clips--during a
>> production of The Producers, with gunshots timed to the beat, I had to
>> add a half dozen blank audio cues just to hope to get the computer to
>> fire the real ones the split second I hit go.
I'm not sure how you're actually trigger the GO but my experience has been
that via a click on the GO box or via a keyboard trigger, it could be any
where from dead on to very late.
The problem seems to go away when triggered via MIDI. Obviously there is
some lag time involved with midi but whatever amount there is seems to be
consistent & fast enough to allow for me to quit worrying about it.
Some times I have a dance cue that is triggered as the dancer leaves the
ground. It has to be dead on or the dancer comes down & we do it
again...:)
If you're already using MIDI to trigger the GO, sorry for the long winded
email.
Best regards,
ra byn (robin)