video playback issues

[mat_kinotek]

hey all,

I'm experiencing erratic freezes on my clips: most of them won't even lunch without pre-loading, and some freeze after few or several seconds, while the timeline keeps on running. 

Clips are around 40sec in average, 1920x1080p, photo-jpeg, keyframes every 100 frames, and I'm launching one clip at the time. 

I'm running 10.9.2 - Maverick on a MacBook Pro 2.8 ghz intel core 2 duo , NVIDIA GeForce 9400M 256 MB, 4gb RAM, SSD 250gb. (I have a qLab 1 day licence).

CPU and RAM are not last models' but I have an SSD and just need to play one clip at the time .. do you know of any issues with Maverick? Or maybe the codec?

Thanks,

M. 

[Dave "luckydave" Memory]

On Monday, March 17, 2014 at 11:16 PM, mat_kinotek wrote:

do you know of any issues with Maverick?

This could be a Mavericks video issue we've found and reported to Apple. Until they fix the underlying issue, we have a hidden preference workaround, which comes at the price of a little more CPU work, so we don't make it user-facing, in case it's not necessary, which it often isn't. Write to us at sup...@figure53.com, and we'll get you instructions.

-- 

luck...@figure53.com 

[micpool]

I don't think Photo jpeg videos use keyframes. They do use the quality setting  to determine the JPEG compression and therefore the quality and file size. High Quality is about 4 times  the file size  (and data rate) of medium.

In terms of playback performance Photo jpeg is quite good. On my Quad core MacBook Pro running 10.8.5 I can run 6 with high quality or 12 at medium quality (identical files to same surface).

For Comparison 422LT starts to choke at around 8.

Don't have a mavericks machine to hand to test

As a test you could also try playing the file off an external disk in case you have an SSD issue.

Mic

[mat_kinotek]

Hey all,

just as an update, I did try playing the clips from an external drive (firewire), it still freezes.

Any other idea?

[micpool]

Did you contact figure53 support as per luckdaves post and get the Mavericks fix?

Have you tried 422LT codec

Have you tried patching a cue to the built in  screen of your MacBookPro (You will lose the duelist but you can hit ESC to get it back. (Obviously no good in a show but would eliminate external monitor or cabling as the culprit)

Mic

[Andy Lang]

On Wed, Mar 19, 2014 at 1:51 PM, micpool <m...@micpool.com> wrote:

Did you contact figure53 support as per luckdaves post and get the Mavericks fix?

Mattia has, and we're investigating with him, as it's not the Mavericks bug.

Thanks!

-Andy

Figure 53 Support

[Dave "luckydave" Memory]

On Wednesday, March 19, 2014 at 11:44 AM, Andy Lang wrote:

On Wed, Mar 19, 2014 at 1:51 PM, micpool <m...@micpool.com> wrote:

Did you contact figure53 support as per luckdaves post and get the Mavericks fix?

It looks like it was a combination of a faster playback rate, combined with PhotoJPEG compression. Since PhotoJPEG uses JPEG block-style compression, and encodes differences from each key frame, it's harder for the computer to keep up with increased playback rate than it is with a progressive codec. Transcoding to ProRes422 (LT) made the difference.

-- 

luck...@figure53.com

[micpool]

I'm getting really confused with your description of PhotoJPEG as a codec that uses key frame differences. Unless we are talking about something else PhotoJPEG applies only spatial not temporal compression. None of my encoders allow keyframe settings for PhotoJPEG.

Mic

[Dave "luckydave" Memory]

On Wednesday, March 19, 2014 at 4:31 PM, micpool wrote:

I'm getting really confused with your description of PhotoJPEG as a codec that uses key frame differences. Unless we are talking about something else PhotoJPEG applies only spatial not temporal compression. None of my encoders allow keyframe settings for PhotoJPEG.

I think you're right. I thought I remembered key frames for PhotoJPEG. At any rate, ProRes 422 LT seems to have helped. PhotoJPEG can use lossy compression, which means it can take longer to decode, or it could be related to file size, with the disk unable to keep up with the faster calls for frames with the increased playback rate.

-- 

luck...@figure53.com 

[micpool]

A few things things occur to me.

It would have been helpful if the OP had said that his problem was playing clips speeded up.

I can get 422 LT playing quite happily at 10-20 times speed on my setup but photoJPEG goes erratic at x3

However, does this mean that the rate control has not been implemented optimally for video? (and audio?)  Surely, the data rate has to be kept to reasonable levels at high speed playback either by sampling fewer frames or lowering the playback quality. For instance in Final Cut Pro X I can easily play photoJPEG clips at 30 times speed in the editor. 

And a final observation. Sometimes when the speed of a cue is increased beyond what Qlab can cope with, Qlab crashes. Other times it just has a bit of a think about it and doesn't crash. It looks to all intents and purposes as if the program is functioning normally but even if the video rates are reset to 1x they play erratically. Is it  the case that as soon as Qlab has a wobble on high speed video that it really needs to be restarted to regain it's performance? 

Mic

On Wednesday, March 19, 2014 9:56:36 PM UTC, luckydave wrote:

[Chris Ashworth]

The rate adjustment is relatively naive for video; it will drop frames from the buffer to catch up to the right time. I’d have to go check code again but I don’t believe it jumps ahead during decoding, so it’s pulling out all the frames, hence choking for high res files if they play back at high rates.

Certainly something I can look at trying to optimize further if that’s a thing that people do. Is it?

(I don’t think the original poster was playing clips speeded up, we just used that to trouble-shoot the problem.)

-C

[Paul Gotch]

On Wed, Mar 19, 2014 at 05:37:43PM -0700, micpool wrote:
> lowering the playback quality. For instance in Final Cut Pro X I can easily
> play photoJPEG clips at 30 times speed in the editor.

You won't be playing PhotoJPEG, Final Cut will have cross coded it to
some form of ProRES when you imported the video.

-p
--
Paul Gotch
--------------------------------------------------------------------

[micpool]

Are you sure??

Final Cut edits in the native codec of the timeline. If what you are suggesting was the case you wouldn't be able to drop a long photoJPEG clip into Final Cut and work with it immediately as it would need a fair bit of time to transcode (and the render file would show up somewhere). An editor such as Final Cut is an example of a program that has to have highly optimised variable speed playback as it will routinely when editing have to play back at any speed in any direction with rapid changes without any degree of stress

Mic

[micpool]

>
> (I don’t think the original poster was playing clips speeded up, we just used that to trouble-shoot the problem.)
>

So if the problem wasn't playing files at excessive speeds what was it that prevented this set up from playing a single layer of 1080p video in photoJPEG reliably ?

Mic

[Christopher Ashworth]

Well, good point, and something I realized after posting; effectively we could stand to try to optimize this even when not playing at higher speed. The problem is the computer couldn't decode the video far enough.

I would propose that even if we made it so the system could stutter through a file that it can't currently play now, that's not much of an improvement. If it is not capable of decoding the media to the degree that it simply stops rendering frames , that's going to be some very stutters playback even if we're able to make it provide some frames some of the time.

(mobile)

> --
> --
> 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.

[Christopher Ashworth]

Bah : "fast enough", not "far enough".

Grumble grumble stupid autocorrect grumble

(mobile)

[James Mapes]

Video rate adjustment is super useful for animations as backdrops - like stars moving, fireflies dancing in a static backdrop, and water animated in a waterfall (to name three examples I've seen used lately). Being able to take a looping clip of 30 seconds of video and finely adjust the speed of it is super useful, and something I've had trouble with in qlab 3.

[Christopher Ashworth]

What was the specific trouble you've had?

(mobile)

> On Mar 20, 2014, at 7:02 PM, James Mapes <mapes...@gmail.com> wrote:
>
> Video rate adjustment is super useful for animations as backdrops - like stars moving, fireflies dancing in a static backdrop, and water animated in a waterfall (to name three examples I've seen used lately). Being able to take a looping clip of 30 seconds of video and finely adjust the speed of it is super useful, and something I've had trouble with in qlab 3.
>

> --

[James Mapes]

In the past, whenever I've played with rates on video, but in particular a 30-sec loop of HD video, the video glitches out, freezes after a couple seconds, and won't ever play again unless I recreate the file. I am now remembering that I haven't attempted in lately... so if that sounds like something you've never heard of, I can give it a go on an updated copy.

--
--
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 a topic in the Google Groups "QLab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qlab/6ywJFhCLbxo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to qlab+uns...@googlegroups.com.

[Chris Ashworth]

Thanks James, this is very helpful.

-C

From: James Mapes mapes...@gmail.com
Reply: ql...@googlegroups.com ql...@googlegroups.com
Date: March 20, 2014 at 10:56:12 PM
To: ql...@googlegroups.com ql...@googlegroups.com
Subject:  Re: [QLab] Re: video playback issues

[micpool]

James' experience seems to be the same as my findings, once a video cue  has had a major freeze due to being played faster than Qlab can cope with, then the cue  won't play again normally. I said until Qlab is restarted. I'm not sure what James means by 'recreating the file' as obviously the actual file won't be affected. I assume, if he is not restarting he means recreating the cue, i.e deleting it and then targeting the video file in a new cue, or perhaps reloading is sufficient.

Mic

[Chris Ashworth]

I’m puzzled about the observation that a cue never plays again normally — my understanding of the issue doesn’t account for that behavior. 

But here is my understanding of the issue, copied directly from the issue I just filed in our bug tracker:

"Our frame buffering algorithm for video uses a background thread to read each frame of a video file into the buffer, and deliver it when needed. If the clock jumps ahead of the current frame in the buffer, we drop that frame and move to the next until we find the one that matches the clock time.

This works well if the computer can decompress the file quickly and keep the buffer full, but if the computer can't handle the file it never catches up and nothing ever plays.

It would be better if we could skip ahead in the actual decoding when we know we're far behind; presumably in some cases it will be better to drop frames regularly than it would be to not play at all."

[micpool]

On Friday, March 21, 2014 2:06:31 PM UTC, Christopher Ashworth wrote:

I’m puzzled about the observation that a cue never plays again normally — my understanding of the issue doesn’t account for that behavior. 

I have just looked at this again and the important thing in trying to get a vaguely repeatable test is what happens when the cue is terminated.

I am using a 1920x1080p clip in Pro Res 422 LT Looped

Plays fine at x1  Plays OK at x10 At Rates around 20x plays erratically but hitting ESC causes a normal termination of the cue and Qlab continues at normal.  At x25 plays erratically and when cue is terminated Qlab locks up with spinning beach ball and needs to be force quitted.

Now, in between  the rate at which the playback is erratic but cues terminate normally and the rate at which Qlab crashes there is another scenario. At say x 23 times playback is erratic and terminating the cue results in a Qlab lock up with spinning beach ball for a few seconds. After this happens and everything looks normal, But the cue will not play at 10x which it did previously and will lock up Qlab when terminated requiring a force quit.

Using photoJPG codec Plays fine at x1. At x5 doesn't play first time through loop but plays OK from second loop onwards. At x8 plays a few frames each time the video loops and takes a few seconds to recover after the cue is terminated.As the rate is increased the recovery time gets longer, and in addition to Qlab freezing for a while the freezing begins to affect the finder.

Another thing that may indicate that something is awry with how the buffers are being cleared; Open Qlab and play a clip at 30x rate. Stop it and repeat. With each play the recovery time gets longer until Qlab crashes.

Now all this may not mean very much, it may just be that Qlab enters an unstable state and how this manifests itself will vary from machine to machine and source file to source file.

However, what would seem to me to be the sensible design goal would be that entering any rate that is allowable (currently a max of 33) would not result in any visible  anomalies and certainly no crashes, in the same way as you would expect an editor to play video at any required speed forward or backwards without crashing or needing recovery time when you stop.

I can't see that you would ever want your actual output to exceed 30fps regardless of the speeded up effect you wish to see. So if the desired playback rate is 4 then (with a 30fps video) you would only need every 4th frame to be decoded in order to maintain an output frame rate of 30fps. This is what would happen if you rendered this out in After Effects. (As long as you weren't using frame blending or motion estimation)  There seems little point in attempting to decode 120fps.

It may even be the case that once the program works in this way that the rate parameter could be animated for video cues in the same way as it can for audio.

Mic

[Joshua Langman]

"I can't see that you would ever want your actual output to exceed 30fps regardless of the speeded up effect you wish to see."

I respectfully disagree, at least to a point. If I drop in a video that is 60 fps, I would expect QLab to honor that and play at 60 fps.

Likewise, if I double the speed of of a 30 fps video in QLab, I would expect it to then become effectively 60 fps. But beyond a certain point this becomes a little ridiculous, that point being the point at which you exceed the refresh rate of the projector. But QLab doesn't know what that is, does it?

[Chris Ashworth]

QLab drives rendering from a CoreVideo display link thread, which (theoretically) runs at the refresh rate of the screen.

I say “theoretically” because the bug Apple introduced in 10.9 is that in some cases they appear to be trying to save power and drop the refresh rate in cases when it is not safe to drop.

-C

[Chris Ashworth]

Thanks for the details Mic, very helpful, I’ll add these to the ticket.

Regarding this:

So if the desired playback rate is 4 then (with a 30fps video) you would only need every 4th frame to be decoded in order to maintain an output frame rate of 30fps. 

One twist here of course is temporal encoding, which may rely on decoding the previous frames to be able to get the next frames.  For codecs that do that, I don’t believe we could arbitrarily skip to any particular frame.  It might be possible to skip to key frames, although I haven’t investigated enough to know if CoreVideo lets us specify doing something like that.

-C

[micpool]

On Friday, March 21, 2014 6:42:54 PM UTC, Christopher Ashworth wrote:

One twist here of course is temporal encoding, which may rely on decoding the previous frames to be able to get the next frames.  

That's a bit academic though. Temporal encoded codecs are in Qlab video what mp3s are in Qlab audio. They might play OK but as soon as you want to do any sort of manipulation of them they are not really fit for purpose. On my machine a 1080p MPEG-4 encoded video won't play at all in Qlab.  A 264 will play at up to 2x speed, but add a video effect and it won't always  play reliably. I think they are utterly pointless in the context of professional video design.

However, like the ability to play mp3s, retaining Qlabs ability to play the widest range of video codecs  is worthwhile for people working in conference and presentations who might have a client turn up with anything on a USB stick, but for a designed show why would you want to use them?

I'm not sure how you manage the expectations of non technical Qlab users though, as obviously Qlab allows you to try almost anything in terms of  inappropriate codecs, large numbers of simultaneous streams, Triple width HD video dimensions, high frame rates. with effects. A lot of these experiments are going to end in disappointment or worse, a crash mid show because the computing  headrooms were marginal and the user didn't realise how marginal until it was too late.

It seems to come to a shock to many people that running 4 streams of 3840x1080 video encoded in MPEG-4 at 60fps with motion blur effect on a Mac Mini is going to end in tears. It's great that Qlab is open ended with regard to how experimental you can be  with crazy stuff to see if it works, but how you then teach people that this power makes them responsible for testing thoroughly anything they are going to attempt to do with their available hardware, and they have to leave a generous reserve of performance if their show is going to run reliably is a real problem.  But that's another thread.

Mic

[micpool]

On Friday, March 21, 2014 6:32:56 PM UTC, Joshua Langman wrote:

. But beyond a certain point this becomes a little ridiculous, that point being the point at which you exceed the refresh rate of the projector. 

Subjectively it's more complex than that. On my 60Hz monitor I can clearly see the difference between an identical 100fps  video rendered out at  100fps and the same video  rendered out at 50fps (sampling every second frame).

It's a difficult balancing act . 100fps can be beautifully smooth particularly for speeded up footage.  But it's another significant performance/reliability hit and another way to crash your show.

Mic