flicker on pause Displays Flickering at Each Pause Cue

[RFrendt]

I am running a show using Watchout 5.5.1 and six displays.  All of the show cues are linear, and so are simply lined up one after another in the main timeline, with a pause cue at the beginning of each video cue.  The video cues are relatively short (5-20 seconds on average), and are all pre-split using video proxies.  They are .mp4 (H.264) files.  I am experiencing some signficant flickering (a quick flash of a black screen) for various displays every time the show reaches one of the pause cues.  On many pause cues, one or more displays go completely black for a fraction of a second before restoring the appropriate still image.  Different displays flicker each time a pause occurs, usually more than one, but they are not consistently the same displays.

 

I am running six display computers, all completely tweaked for Windows 7:

 

Dell Latitude E6500

Intel Core 2 Duo @ 2.4GHz

4GB DDR2 RAM

64 GB SSD

1920x1200 Display

NVidia Quadro NVS Graphics

Windows 7 Pro SP1 x64

Watchout 5.5.1

 

The flickering doesn't occur on every cue, but for many of them.  I have tried re-rendering the resolution of the cues down by half, just to see if this was related to a performance issue on the display computers' part, but lowering the resolution has virtually no effect.  The video cues all seem to play fine, except for the flickering at the pause cues, which is very distracting (this is a theatrical application, the cues appear on a very large backdrop, so the flickering is very noticeable).  I have no idea on what to try, or check next.  Any thoughts?

 

Regards,

Rick

 

 

[jfk]

It sounds like you are running using the Production comptuer in the system.

(If you were running in cluster mode with a single computer, this would likely not occur).

 

When running from production, it may be a symptom of a network issue (UDP traffic blocked)

which causes loss of the network timing / synchronization data - the display will drift,

resulting in an overshoot at the pause.

and a goto being executed (the momentary black) to return to the correct pause point.

(And yes, I have seen displays drift in less than 10 seconds when UDP is blocked).

[Neil Stratton]

Hi Rick - I had a similar problem years back and Jonas Dannert advised to render MPEG-2 files with all I-frames (key-frames on every frame), And it worked.

Here is the thread

 

http://forum.dataton.com/topic/100-pause-a-movie-file/?hl=frame&do=findComment&comment=1747

[zackboyd]

Is it possible to place the pause cue 0.5 seconds(half a second) before the start of the cue? Give the display servers an opportunity to pre-roll into the clip(s).

[jfk]

All good suggestions ...

 

Hi Rick - I had a similar problem years back and Jonas Dannert advised to render MPEG-2 files with all I-frames (key-frames on every frame), And it worked.

Here is the thread

 

 

Pause a movie file

The referenced thread is about pausing in the middle of a movie roll

and continuing on with the same movie file.

All I-frames would be a big advantage when doing that.

 

There are advantages and disadvantages in all I frames,

you could push past your hardware's threshold.

 

from original post ...

 

... with a pause cue at the beginning of each video cue. ...

I read that a bit different.

Where a pause delineates the ending and beginning of separate movie cues,

all I frames are not as crucial.

 

Probably more important is to be sure there are no B frames used -

this is also indicated in Pause a movie file referenced above as well.

That thread pretty much expands on the recommendations

in WATCHOUT - Codecs for stable WATCHOUT playback - 2012.pdf

Is it possible to place the pause cue 0.5 seconds(half a second) before the start of the cue? Give the display servers an opportunity to pre-roll into the clip(s).

That is good advice, although 0.5 is very conservative.

Even 0.1 after pause is better than placing them at the exact time of the pause.

 

But the benefit is not about movie pre-roll,

the movies were pre-rolled even before the pause cue was encountered.

 

The benefit has to do with transitioning from run state to pause state or

from pause state to run state - both state changes add additional housekeeping chores.

So there is a spike in processor demand during the state transitions.

By providing a little breathing space around the pause,

you reduce the spike.

 

But of all the suggestions, please consider trying mine first.

It involves no reprogramming or re-encoding.

To test ...

Use your production comptuer, but do not open the production software.

If you do not have WATCHOUT Remote 1.1 (last post in the thread)

on your Production Computer, take the time to install it.

Detail on WATCHOUT Remote can be found in the user guide for

WATCHOUT Systems Manager, Chapter 2 - Remote Control Application.

BTW WATCHOUT Remote requires no license key,

runs on PC or Mac (and with a different link iOS, Android, etc)

Restart the display computer so that it is at the logo screen.

Run WATCHOUT Remote on your production computer

to open and run your show cues.

See if that does not eliminate the issue.

If it does not, try adjusting the spacing of cues around the pause as discussed above.

 

Last, consider movie re-encoding.

 

One way or the other, this can be made to work correctly.

[Neil Stratton]

Having reread your post I second Jim's suggestion .This looks more like a processor demand issue, not an encoding one. Good luck!

[RFrendt]

Thanks all - I'll try Watchout Remote at the theatre tonight, and report back.  I had previously tried to move the pause cues just before the end of the cue to no effect - the flickering simply happened wherever the pause occurred.  I am hoping not to re-render, since my resolution format (1920x1200) won't work in MPEG-2.  Fingers crossed...

 

Regards,

Rick

[Thomas Leong]

The Dell Latitude E6500 is a laptop, albeit a reasonably equipped laptop.

 

Since you said you are running 6 display pcs, are you saying you are using 6 of the said Dells (one output each)? Not sure if this could be the cause, but if so, check that each Dell has the NVidia Quadro NVS Graphics card selected as THE Preferred graphics card to use instead of the on-board Intel^® Graphics Media Accelerator 4500MHD. You do this via the NVidia Control Panel found in Windows Control Panel.

[RFrendt]

Yes, I believe each of the laptops does have the NVidia card set as the preferred graphics card, but I will double-check just to be sure.

 

Rick

[RFrendt]

Well, the problem appears to have been solved, though I have to admit I'm not sure why.  I first tried running the show through Watchout Remote instead of from the production software on the control computer, but this didn't seem to have much effect on the flickering (it may have reduced it a bit, but that might have just been my imagination).  I had earlier tried moving the pause cue forward a few frames before the end of an offending video cue, and that didn't help either, the flickering simply occurred where the cue was set.  However, today I tried moving the pause cue back  a few frames (just 2 or 3) past the beginning of the next video cue, and that solved the problem in every single case.  I'm very grateful that this is working now (and so is my client), but I don't understand what's going on technically that would make this solution work.  I would love to understand this better so I can adjust appropriately in the future.  Any thoughts?

 

Appreciatively, 

Rick

[Walter]

Rick, please note that 1920x1200 is very well possible as mpeg2. Perhaps not directly from the editing program or AME or such, but using ffmpeg you should encounter no issues.
Good luck, looking forward to your experience with the suggested solution(s).

Walter

[Adam]

I'm encountering a similar challenge, but possibly not the same cause: I'm seeing a black stutter each time the playhead stops at a pause cue in any area routed by more than one layer of VDs - meaning I have an area of the stage where I’m assembling content with a VD camera pointed at it. Then that camera gets pasted below several times, each with a different mask associated. Those are, in turn captured by different VD cameras which are again in turn reassembled in another area of the stage to several display outputs with various scaling/corner pinning on each. Its rather complicated but conceptually effective. The two level VD thing appears to be the root of the issue as the flicker is not showing up in any areas of content not double routed. I have no movie files in my timeline, all assets are psds (either HD or up to UHD res). Preroll also doesn't apply since the way I'm using virtual displays by design are continuous over the entire timeline, they're routing tools. Has anyone encountered this before and know whether there's a work-around? Or should the rule of thumb be do not use two layers of virtual displays ...

[MelissaPeterss]

I had previously tried to move the pause cues just before the end of the cue to no effect - the flickering simply happened wherever the pause occurred. 

[Brian]

This has been an issue for me in WatchOUT for as long as I can remember. I don't have this issue with any other media server. The fix has always been to just play around with pause points and pre-roll times (setting manual, longer pre-roll has helped) but I have never found a solid, consistent solution for this issue in WatchOUT.