Re: [QLab] Qlab slow to trigger and glitchy with multiple videos
1,212 views
Skip to first unread message
Lucas Krech
Nov 22, 2012, 10:37:43 AM11/22/12
to ql...@googlegroups.com
I've not had good luck with H.264 personally. My understanding is it has something to do with the work needed to uncompress the files from disk. I have had better success with codecs like ProRes422(LT) which seem to require less work to reach the data. They are a lot bigger but seem to read faster and hiccup less.
-L
Lucas Benjaminh Krech
Lighting and Video Artist
Twitter: lucaskrech
- - - - - - - - - - - - - - - - - - - - - - -
"What I give form to in daylight is only one percent of what I have seen in darkness."
~M.C. Escher
On Nov 22, 2012, at 6:54 AM, Ant Tones wrote:
Hello,We are currently working on a show that requires multiple video playbacks through qlab. We have noticed firstly that our video cues are slow to trigger (even when loaded there is a slight delay). Secondly when overlaying multiple videos they seem to jump and freeze.The setup we are currently running is as follows.Mac Pro OSX 10.6.82x2.25ghz Quad core intel Xeon16GB 1066 MHZ DDR3 RAM4 x NVIDIA GEFORCE GT120 (VRAM 512MB)From this we are running 3 x projectors through VGA.The only thing we can consider is that the Graphics cards don't have the VRAM capable of running multiple overlaying video files (majority of which are H.264)If anyone can part any knowledge on this or offer any solutions we would be extremely grateful.Cheers--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab
Follow Figure 53 on Twitter: http://twitter.com/Figure53
Mike P
Nov 22, 2012, 11:13:12 AM11/22/12
to ql...@googlegroups.com
I've had the opposite experience. You keep hearing that there is no magic bullet and this is a good example. I get a lot of stutter and freeze with ProRes probably because of disk access time. H.264s, on the other hand, are small and get off the disk fast and the decompression seems to not be as much of a problem. I only use ProRes and Animation when I need an alpha channel and I keep those as small as possible. You should try a few scenarios and see what works best.
One thing you might check is the quality you have set for your h.264s. I find I can get away with medium to low quality on a large file and it eliminates some of the loading problems.
Also - something I've noticed even with PNG stills is a Load is a potential big performance hit. I've had to restructure long sequences and trick QLab into only loading what it needs or getting things loaded way ahead of time when I can afford the hit. If you hit a big load in the middle of a big playback, it often causes a freeze.
Mike Post
(601) 307-8657
mdp...@mac.com
http://mdpostdesign.com
One thing you might check is the quality you have set for your h.264s. I find I can get away with medium to low quality on a large file and it eliminates some of the loading problems.
Also - something I've noticed even with PNG stills is a Load is a potential big performance hit. I've had to restructure long sequences and trick QLab into only loading what it needs or getting things loaded way ahead of time when I can afford the hit. If you hit a big load in the middle of a big playback, it often causes a freeze.
Mike Post
(601) 307-8657
mdp...@mac.com
http://mdpostdesign.com
Lucas Krech
Nov 22, 2012, 12:10:23 PM11/22/12
to ql...@googlegroups.com
Perhaps more than codecs it seems that the difference between file dimensions and output size are a major factor. If you are moving and streatching via custom geometry that can get laggy with multiple overlapping files.
Honestly, codecs are like this magical alchemy to me. And every time I feel I've got handle on it, my rules fall apart.
I've noticed PNGs being very laggy. But there were a bunch overlaid with custom geometry and transparency last I used them so too many variables to isolate.
-L
Lucas Benjaminh Krech
Lighting and Video Artist
Twitter: lucaskrech
- - - - - - - - - - - - - - - - - - - - - - -
"Lighthouses are more helpful than churches."
~Benjamin Franklin
sam kusnetz
Nov 22, 2012, 12:43:41 PM11/22/12
to ql...@googlegroups.com
Folks have said good stuff. Here are some useful things to think about re. codecs:
1. ProRes 422 (LT) is just one of several flavors of ProRes, and is the one that most QLab users have reported upon favorably. ProRes 4444, for example, is much, much more taxing on the computer than 422 LT.
2. I think the main reason that different people have such difference experiences is because there are enough variables in video (frame rate, data rate, resolution, disk speed, GPU spec, and more) that it's rare that two different setups have all those variables in the same state.
3. A good rule of thumb is that H.264 is easy on the disk but hard on processing, and ProRes 422 LT is the opposite. PhotoJPG is somewhere in the middle.
4. A great troubleshooting technique is to re-render your video at a lower data rate and try it out. Depending upon performance conditions, you can often get the data rate surprisingly low before visibly degrading the image, and that's a great way to improve playback responsiveness.
5. Always, always keep the resolution of your imagery as low as possible. This is the easiest thing to fix. If your projector is natively 1024x768, the only reason you should have imagery larger than that is if you want to zoom in on it. There is no quality improvement to be had feeding a 1920x1080 image to that projector and making QLab or the projector scale it down.
6. In terms of basic performance, full screen cues are less taxing on the computer than custom geometry cues. Cues sent to a single video output are less taxing than cues that span multiple outputs. Two copies of a cue running simultaneously, one to each of two outputs, can be better than one cue running to both.
7. The main rule is experiment! Make copies of your video in different codecs and try them out.
Happy Thanksgiving to all!
Cheerio,
Sam
--
Sam Kusnetz
QLab Support Operative
s...@figure53.com
1. ProRes 422 (LT) is just one of several flavors of ProRes, and is the one that most QLab users have reported upon favorably. ProRes 4444, for example, is much, much more taxing on the computer than 422 LT.
2. I think the main reason that different people have such difference experiences is because there are enough variables in video (frame rate, data rate, resolution, disk speed, GPU spec, and more) that it's rare that two different setups have all those variables in the same state.
3. A good rule of thumb is that H.264 is easy on the disk but hard on processing, and ProRes 422 LT is the opposite. PhotoJPG is somewhere in the middle.
4. A great troubleshooting technique is to re-render your video at a lower data rate and try it out. Depending upon performance conditions, you can often get the data rate surprisingly low before visibly degrading the image, and that's a great way to improve playback responsiveness.
5. Always, always keep the resolution of your imagery as low as possible. This is the easiest thing to fix. If your projector is natively 1024x768, the only reason you should have imagery larger than that is if you want to zoom in on it. There is no quality improvement to be had feeding a 1920x1080 image to that projector and making QLab or the projector scale it down.
6. In terms of basic performance, full screen cues are less taxing on the computer than custom geometry cues. Cues sent to a single video output are less taxing than cues that span multiple outputs. Two copies of a cue running simultaneously, one to each of two outputs, can be better than one cue running to both.
7. The main rule is experiment! Make copies of your video in different codecs and try them out.
Happy Thanksgiving to all!
Cheerio,
Sam
--
Sam Kusnetz
QLab Support Operative
s...@figure53.com
Lucas Krech
Nov 22, 2012, 1:12:46 PM11/22/12
to ql...@googlegroups.com
Well stated. This would make a good FAQ on the wensite.
-L
Lucas Benjaminh Krech
Lighting and Video Artist
Twitter: lucaskrech
- - - - - - - - - - - - - - - - - - - - - - -
"Don't tell me the moon is shining; show me the glint of light on broken glass."
~Anton Chekhov
Angus Turner
Nov 22, 2012, 6:58:33 PM11/22/12
to ql...@googlegroups.com
One thing to note is in many of the more modern computers there is hardware decoding of H.264. Don't think this applies in your situation though.
Thanks
Angus Turner
angus...@gmail.com
Thanks
Angus Turner
angus...@gmail.com
deepvisual
Nov 25, 2012, 7:04:14 AM11/25/12
to ql...@googlegroups.com
I had the same problem. the best solution is to re-render all the clips into one big clip and run that.
A simple workflow would be to position your clips, take a screenshot then use that as a guide in AFX or whatever.
A simple workflow would be to position your clips, take a screenshot then use that as a guide in AFX or whatever.
G
deepvisual
Nov 25, 2012, 8:57:15 AM11/25/12
to ql...@googlegroups.com
I think this is a problem specific to Qlab, not the codec. The regular video playback software I use preloads the first few seconds of clips in RAM so they trigger instantly. Qlab doesnt seem to do this. the Preload function just seems to start clips from a specific point. It would be a big help to make Qlab more video friendly, especially with regards to live input, as firewire is around ten years out of date.
Christopher Ashworth
Nov 25, 2012, 9:28:25 AM11/25/12
to ql...@googlegroups.com
On Nov 25, 2012, at 8:57 AM, deepvisual <ga...@deepvisual.com> wrote:
> I think this is a problem specific to Qlab, not the codec. The regular video playback software I use preloads the first few seconds of clips in RAM so they trigger instantly. Qlab doesnt seem to do this.
QLab does preload video.
> I think this is a problem specific to Qlab, not the codec. The regular video playback software I use preloads the first few seconds of clips in RAM so they trigger instantly. Qlab doesnt seem to do this.
> the Preload function just seems to start clips from a specific point.
> It would be a big help to make Qlab more video friendly, especially with regards to live input, as firewire is around ten years out of date.
I am happy to report that v3 does not use QuickTime, and look forward to sharing more details soon.
-C
Reply all
Reply to author
Forward
0 new messages