Choppy video on every other playback

1,265 views
Skip to first unread message

Rob Kettridge

unread,
Nov 7, 2014, 5:04:08 AM11/7/14
to ql...@googlegroups.com
Good morning

Wonder if anyone can help me on a recurring problem. Doesn't appear to be linked to a particular video file or computer, all running latest version of QLab 3.

New workspace with one video file in going to a single screen, nothing complicated. Play the video, plays fine. Stop the video, play video again, plays back choppy. Stop the video, play the video again, plays fine. Stop the video, play the video, plays choppy... etc etc...

I even had it once where i looped the first 5 seconds or so of a video file and every other loop it would be choppy.

Thoughts?

This has happened most noticeably on our macbook pros (The last ones before the optical drive disappeared).

Rob Kettridge


Chris Ashworth

unread,
Nov 8, 2014, 9:53:12 AM11/8/14
to ql...@googlegroups.com
For the list archive, it appears this was due to an underpowered video card.

Rob Kettridge

unread,
Nov 10, 2014, 5:06:26 PM11/10/14
to ql...@googlegroups.com
Hi Chris.

This is a different issue from the one i was talking to email support about.

Thanks

Rob Kettridge

Chris Ashworth

unread,
Nov 11, 2014, 9:34:39 AM11/11/14
to Rob Kettridge, ql...@googlegroups.com
Ah, apologies.   My unhelpful answer is that I’ve never heard of this happening and don’t really have a theory as to why it would… 

Rob Kettridge

unread,
Oct 1, 2015, 11:53:08 AM10/1/15
to QLab, r...@kettridge.co.uk
Right, revisiting this as it's currently appearing again on today's job.

Single video file, supplied by our video department. h264 .mp4 file. 1080p50.

Now i'll say from the start i've discovered this is not a QLab problem but an underlying Quicktime problem. The same problem occurs if you open the file in quicktime, put it on the external output and make it full screen.

For a quick recap.... it seems to be hit and miss as to how smooth the playback is. At best it looks like it should, at worst it looks like it's running at about 10fps. There's no variance once the file is running (i.e. if it starts bad it plays all the way through bad). It now appears that it's not alternate and also that it's not so black and white as to how bad it is. Sometimes it's just not quite right.

Also this is now running on two brand new retina macbook pros with the discrete graphics chip and 2GB of video memory. Both machines exhibit the same behaviour but not at the same time. I'm hoping tonight (seeing as i'm running main and backup) that one will be fine whist the other one breaks.

Really bashing my head against the wall now....

Rob

Sam Kusnetz

unread,
Oct 1, 2015, 11:55:55 AM10/1/15
to ql...@googlegroups.com

Rob

I strongly encourage you to run this file through Compressor and re-encode it. This really sounds to me like an encoding problem.

While you're there, you might as well transcode it to Pro Res 422 Proxy which is our recommended and preferred format for video playback in QLab.

If you do not own Compressor, I can comfortably say it's $49 well spent if you ever encounter problems like this one.

Best
Sam


October 1, 2015 at 11:53 AM
Right, revisiting this as it's currently appearing again on today's job.

Single video file, supplied by our video department. h264 .mp4 file. 1080p50.

Now i'll say from the start i've discovered this is not a QLab problem but an underlying Quicktime problem. The same problem occurs if you open the file in quicktime, put it on the external output and make it full screen.

For a quick recap.... it seems to be hit and miss as to how smooth the playback is. At best it looks like it should, at worst it looks like it's running at about 10fps. There's no variance once the file is running (i.e. if it starts bad it plays all the way through bad). It now appears that it's not alternate and also that it's not so black and white as to how bad it is. Sometimes it's just not quite right.

Also this is now running on two brand new retina macbook pros with the discrete graphics chip and 2GB of video memory. Both machines exhibit the same behaviour but not at the same time. I'm hoping tonight (seeing as i'm running main and backup) that one will be fine whist the other one breaks.

Really bashing my head against the wall now....

Rob

On Tuesday, 11 November 2014 14:34:39 UTC, Chris Ashworth wrote:
--
--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab
 
Follow Figure 53 on Twitter: http://twitter.com/Figure53

---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
November 11, 2014 at 9:34 AM
Ah, apologies.   My unhelpful answer is that I’ve never heard of this happening and don’t really have a theory as to why it would… 

On November 10, 2014 at 5:06:29 PM, Rob Kettridge (r...@kettridge.co.uk) wrote:

--
--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab
 
Follow Figure 53 on Twitter: http://twitter.com/Figure53

---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
November 10, 2014 at 5:06 PM
Hi Chris.

This is a different issue from the one i was talking to email support about.

Thanks

Rob Kettridge

On Saturday, November 8, 2014 2:53:12 PM UTC, Christopher Ashworth wrote:
--
--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab
 
Follow Figure 53 on Twitter: http://twitter.com/Figure53

---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
November 8, 2014 at 9:53 AM
For the list archive, it appears this was due to an underpowered video card.

On November 7, 2014 at 7:14:07 AM, Rob Kettridge (r...@kettridge.co.uk) wrote:

--
--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab
 
Follow Figure 53 on Twitter: http://twitter.com/Figure53

---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
November 7, 2014 at 5:04 AM
Good morning

Wonder if anyone can help me on a recurring problem. Doesn't appear to be linked to a particular video file or computer, all running latest version of QLab 3.

New workspace with one video file in going to a single screen, nothing complicated. Play the video, plays fine. Stop the video, play video again, plays back choppy. Stop the video, play the video again, plays fine. Stop the video, play the video, plays choppy... etc etc...

I even had it once where i looped the first 5 seconds or so of a video file and every other loop it would be choppy.

Thoughts?

This has happened most noticeably on our macbook pros (The last ones before the optical drive disappeared).

Rob Kettridge


--
--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab
 
Follow Figure 53 on Twitter: http://twitter.com/Figure53

---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Sam Kusnetz | Figure 53 Field Operative
s...@figure53.com

Rob Kettridge

unread,
Oct 1, 2015, 11:58:48 AM10/1/15
to QLab, r...@kettridge.co.uk
Should have mentioned... outputting via inbuilt HDMI to a black magic 1ME production studio 4k, 1 is going to the HDMI in and the other is going via an external HDMI to SDI converter but has also happened with other computers and thunderbolt to DVI and into analogue way switchers..

Rob

Sam Kusnetz

unread,
Oct 1, 2015, 12:00:32 PM10/1/15
to ql...@googlegroups.com, r...@kettridge.co.uk

This could be a good opportunity for me to say something that's probably
unpopular, but nevertheless is a thing I believe:

H.264 is a good format for YouTube and just about nothing else.

More specifically, it is a BAD format for random-access live playback.

Best
Sam

micpool

unread,
Oct 1, 2015, 12:48:50 PM10/1/15
to QLab, r...@kettridge.co.uk
I would add the following:

The reason ProRes (proxy or LT) is better than h264 for QLab  is simple…. you know exactly what you are getting.

There are so many variables in setting up a h264 encode, that the chances of getting a file that plays well in QLab are less than the chances of getting one that  performs poorly.

For about 4 hours, about a year ago, I was of the opinion that h264 was a very good codec. That was because, by complete fluke,  I tested it with h264 output, straight off the CF card shot with a Canon 7D. This outperformed ProRes in QLab in my tests.

I then encoded my own h264s using  lots of different software compressors and never got one remotely as good as the Canon hardware compression. On some common software compressors, I produced files, using the standard settings that would barely play at all in QLab.

From that moment I have only used ProRes in all my QLab shows. The data rates are predictable and constant, and there is no guesswork necessary with settings that are really difficult to understand, like GOP patterns,  to get a good encode.

I still use h264 for making small files for viewing purposes. The files that the export command in QuickTime Player produces using the middle set of codecs (480p, 720p, and 1080p) are very compact files that play very well in QuickTime Player and browsers on the Mac and are well suited for general distribution purposes.

Re-encoding h264 to ProRes may get you a file that plays more smoothly, but don't judge the look of ProRes from the resulting file. It won't be representative of the quality that can be achieved with a direct ProRes encode (or a ProRes encode from a lossless or ProRes HQ Master)


Mic

Rob Kettridge

unread,
Oct 1, 2015, 1:05:02 PM10/1/15
to QLab, r...@kettridge.co.uk
Have just tried converting to ProRes proxy and the problem still remains. :(

Also most jobs we do we have no say on the video. We just get handed a usb stick with video files on generally. Some are ok, some are terrible. Would be good to have a work flow that i can apply to all videos i get on site to make sure i'm playing them back as good as possible.

Andy Lang

unread,
Oct 1, 2015, 1:17:11 PM10/1/15
to ql...@googlegroups.com, r...@kettridge.co.uk
On Thu, Oct 1, 2015 at 11:53 AM Rob Kettridge <r...@kettridge.co.uk> wrote:
Now i'll say from the start i've discovered this is not a QLab problem but an underlying Quicktime problem. The same problem occurs if you open the file in quicktime, put it on the external output and make it full screen.

Just to expand a bit on my teammate Sam's post, this is the key to why we can say, with near certainty, that this is an issue with the file, rather than QLab or the computer. 

The reason for that is that QLab 3 does not use the Quicktime framework to decode video. It uses AVFoundation, a newer media framework that Apple provided to replace the Quicktime framework, which it is phasing out. 

(Quicktime Player is not the same as the framework, although it does use it as it's media decoding engine.)

So if the problem happens in Quicktime and in QLab, that means it's happening with both frameworks, which means it's happening at the file level or, possibly, at the hardware level. But Quicktime (the player) takes a lot of liberty with file playback to make it work on the given hardware, which would be unacceptable for QLab to do, so if it's showing the problems there, it's less likely that it's not in the file. 

Have just tried converting to ProRes proxy and the problem still remains. :(

Did you convert from the original media, or did you just re-convert the H.264 copy? If the latter, it's possible, if not almost certain, that the problem is in the video itself, and the only way to solve that is to go back to the original source and re-encode it from scratch. 
 
Also most jobs we do we have no say on the video. We just get handed a usb stick with video files on generally. Some are ok, some are terrible. Would be good to have a work flow that i can apply to all videos i get on site to make sure i'm playing them back as good as possible.


Unfortunately, there's no magic bullet to find. If a problem is encoded into a source file, it's there, and there's no way to remove it without going back to before the problem was encoded into the file. 

The only way to ensure perfect playback is to ensure that you are provided media in an appropriate format. Clearly communicate the needs beforehand to whoever is providing the media, and make it clear that if those requirements are not met, you won't be able to play the media, period. It's a sad fact of our industry that no only means no if you enforce it. 

Also, to be absolutely certain, make sure you have optimized both computers for best performance by following Sam's guide at:


Also, make sure anything else unnecessary isn't running. Screen sharing, in particular, can cause no end of graphics problems when running high end video software like QLab.

-Andy

Rick Malone

unread,
Oct 1, 2015, 1:37:42 PM10/1/15
to ql...@googlegroups.com
So how about more info on Compressor?  There seems to be several products with that name.

--
--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab
 
Follow Figure 53 on Twitter: http://twitter.com/Figure53

---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Rick Malone
Resident Sound Designer
The Classic Theatre of San Antonio
image001.png

luckydave

unread,
Oct 1, 2015, 1:39:38 PM10/1/15
to ql...@googlegroups.com
On October 1, 2015 at 10:37:41 AM, Rick Malone (soun...@gmail.com) wrote:
So how about more info on Compressor?  There seems to be several products with that name.

Compressor is available on the Mac App Store, and it's made by Apple. It should be a part of any video programmer's toolkit, so you can get a bunch of files at the last minute from people who haven't communicated with you in advance at all, and just drag them into Compressor and batch transcode them before even attempting to play them back. It gives you the chance to start from a known quantity.

-- 
luckydave

Joshua Langman

unread,
Oct 1, 2015, 3:14:09 PM10/1/15
to QLab

Pierre-Luc Brunet

unread,
Oct 1, 2015, 9:14:06 PM10/1/15
to QLab
I'm not sure if this will help you out in your current situation, the people of Figure53 would know best, but you could try this:

Quit QLab, and launch Terminal (which you can find in your /Applications/Utilities folder), and type the following into the command line when it appears:


defaults write com.figure53.QLab.3 ReduceOpacity -bool YES


Hit Enter, and a new command line should appear (that's the only confirmation you'll get that the command took). You can quit Terminal now, and relaunch QLab.


I believe this is usually to fix issues with one surface spanning multiple displays but why not give it a shot and see if it helps.

This workaround is to help work around a bug in the OS but comes at the cost of more CPU usage but in your case shouldn't be a problem.


Have you gone through Sam's prepare, execute, troubleshoot settings?


Is it better?

Sean Dougall

unread,
Oct 2, 2015, 11:00:36 AM10/2/15
to ql...@googlegroups.com
I would agree that it’s worth a shot. If the problem only shows up in QuickTime if you specifically drag it to an external display and go full-screen, then I think it’s not likely to be an encoding issue. I can’t say that this definitely looks like the issue—it’s true that this generally does only affect multiple displays—but we’ve lately started seeing some evidence that something in OS X has changed such that the problem now manifests in slightly different ways.

At any rate, it doesn’t hurt to try. If it doesn’t turn out to help, it’s safest to switch the workaround back like so:

1) Quit QLab
2) In Terminal, type: defaults write com.figure53.QLab.3 ReduceOpacity -bool NO
3) Hit Enter, and launch QLab

And do be careful of capitalization with the “defaults” command; it will fail silently if not typed exactly as above.

--
Sean Dougall


Rob Kettridge

unread,
Oct 6, 2015, 6:57:28 AM10/6/15
to QLab
Right, have had some time to sit down in the office and give this a thorough going over with much google searching. I've ditched everything so it is literally a rMacbook pro, HDMI out into a 32" 1080p TV.

The terminal command didn't make any difference, and i checked it many times so it was definitely put in right. I've also checked with another video cueing playback software and it suffers the same issue. Also using VLC if i span the video window over the two screens it's smooth on the internal half and choppy on the external.

However it appears that changing the display refresh to 60Hz solves the issue as far as i can tell. There's still a small amount of stuttering, but that's to be expected seeing as all our video over here is 25 or 50hz so there'll be some catching up to do every now and again. At least it's constant from one playback to another

Running at 60Hz isn't really an issue as everything over here is 50hz but it may explain why not many people have noticed it if it's all fine on 60hz. 

Just tried forcing the internal screen to 50hz using SwitchresX (makes a mess of that screen output) and that hasn't helped. 

Rob

Rob Kettridge

unread,
Oct 7, 2015, 6:51:02 AM10/7/15
to QLab
Sorry just re-read that. Should say "Running at 60Hz isn't really an option..."

Rob Kettridge

unread,
Oct 22, 2015, 8:27:40 PM10/22/15
to QLab
Just in case anyone is following this... still haven't found a solution but have filmed it to give some kind of idea what i'm talking about. Unfortunately the digital image stabilisation on my phone appears to have removed some of the stuttering but you get the idea....


Rob

Jim Stark

unread,
Nov 15, 2015, 1:12:13 PM11/15/15
to QLab
Underpowered video card, eh?

I'm having terrible trouble trying to run a show from a Mac Mini.  It's the best machine I have available, but I just can't get a projector to work reliably.  I've tried three different projectors; many configurations of output ports.  Am I chasing the proverbial untamed waterfowl?

Thanks.


Sam Kusnetz

unread,
Nov 16, 2015, 9:57:33 AM11/16/15
to ql...@googlegroups.com
That depends on your goals.

I've found that using a Mac Mini with 16 GB of RAM, a nice, fast SSD,
and an i7 processor, I can get reliable performance from QLab playing
back up to two layers of ProRes 422 LT footage to a single 1280x800
projector.

If you can describe your cueing goals more thoroughly, I will be able to
help you assess whether your Mini is up to the task or not.

Andy Lang

unread,
Nov 16, 2015, 11:15:06 AM11/16/15
to ql...@googlegroups.com

On Sun, Nov 15, 2015 at 1:12 PM Jim Stark yojimb...@gmail.com wrote:

I'm having terrible trouble trying to run a show from a Mac Mini.  It's the best machine I have available, but I just can't get a projector to work reliably.  I've tried three different projectors; many configurations of output ports.  

Just to make sure you’re not running into an entirely different problem, can you make sure that you’re using the most up to date QLab release, 3.1.17? You can check this by going to the QLab menu and choosing “About QLab…” The previous release, 3.1.16, had some significant video performance problems in certain situations, so it’s important to make sure you’re not using that release.

Thanks!

-Andy


Andy Lang
@SoundGuyAndy
sup...@figure53.com

Reply all
Reply to author
Forward
0 new messages