Video macro only showing a portion of the frames

[arw01]

have a couple video loops that show the first word of the video, but don't finish or startto display the other frames that would have the rest of the words:

E.g. Merry Christmas only display Merry TUNE TO 107.5 FM displays only tune to

[rmonty]

What did you have the frames per second set to for the macro? Was the macro drawn long enough to encompass the time needed to show the entire video?

[arw01]

I just re-did it again to make it 10.95 seconds long on the macro.

Windows tool tip says 0:06 long, windows details in file listing says 6 secs long, watching it shows 6 seconds in the player bar.

In preview in the macro never completes, it just starts to show the Merry after 8-9 seconds a second time instead of Christmas.

The speed slider is scaled too much to slowing down and not enough to speeding up.

[rmonty]

Speed slider? The scroll speed slider is only used for if you have the video moving in a direction, i.e. not stationary.

[arw01]

Yeah that one, needs more speed...

[LightShowStudios]

Currently the video macro pulls frames out of the video at the rate of the video up to the number frames that needs to be generated (i. e. (length of macro effect/1000) * fps set in macro tool). Probably what is happening is the video fps is much faster than the 20 fps maximum set in the macro tool. The only addition we can add is possibly adding a frame skip option to skip frames in the video. Thoughts?

[arw01]

That one video is 10 seconds long, the video speed shows 24 frames a second. That is a maximum of 40 frames dropped, if it drops them all at the end, then we see the problem.

Frame skip is a possible solution. Increasing the number of frames pulled in the macro seems a better long term solution and giving a speed slider, the skipping can be done in playback, but ultimately I believe you will increase your frame rate out of LSP to more than 50ms aka 20. Video requires 24 for smooth, so dropping to a 40 ms frame rate would get us 25fps.

[rmonty]

Increasing past 20 fps wouldn't make a difference as the grid is only 20 fps. Increasing past the 20 fps becomes kind of useless when most protocols can't handle much faster. It would be a pretty preview, but output wouldn't gain much. And it would come at a cost of memory and performance.

[arw01]

I've not found any protocol limitations that would be as low as 20 or even 25 frames a second, sACN is supposed to not exceed maximum dmx refresh at approx 44hz.

We had some diyla hardware that capped at 50ms output, but I routinely see users in the 25ms and some misguided soles at 10ms for their displays.

At some point the ultimate goal of this software will be to make money, and a statement like:

LSS/LSP only as a 20 frame per second video/output, it does not look as good as XYZ because it outputs at 50 frames a second, smoother is better.

Damage is done, perception is reality. That's why your wife says you are late all the time or never listen :)

I fully understand the trade offs, and the other desire to reduce support. As programmers you know quick and dirty will always come back to bite you vs doing it right the first time. I believe you will argue ad naseum with users if you drop frames to solve the issue, vs pushing up the performance a bit. Having a limit of 24 or so frames a second could be workable as that was what the older version did.

Then again you could just drop a few frames and not say anything :)

[LightShowStudios]

We will look into it. 40 fps would be the lowest we would go as that would be more than adequate for smoothness. Really anything below 30 fps is probably unnoticeable to most.

Unfortunately a byte is a byte and there is no compression to save memory below that. Even other software will significantly use memory when you raise the fps as each frame takes some amount of storage. In our case we have reduced the amount of storage to the lowest we can go. Our lowest item we have is a color which takes 3 bytes (Red, Green, Blue). Let's assume no overhead to keep it simple. For a 10 second effect, this would be storing 400 color "storages" for one node as we have to assume worst case and that we will always be changing each frame. Remember this doesn't include command overhead. Now let's take a 6528 node matrix (i.e. 96x68). So 3 bytes x 400 x 6528 = 7833600 bytes, or 7.8 Mb. You can see now that memory will stack up very quickly the more you increase frames. This is only for 10 seconds. Multiply x 30 for a 5 minute song and you have over 235 Mb for a single object. Macros will also take much longer to generate the more frames you have with little benefit in visual.

Now we do tricks like data virtualize to help keep memory consumption down, but that comes at a cost also as you may have some loading delays and such. We also do tricks in storing nodes with same color at a particular frame.

It's really a balancing act. Currently we feel 20 fps is adequate as it uses about half the memory. If you export to FPP or the Conductor, guess what, you export at 20 fps as that is what those can handle.

We actually have made it a single setting for the entire program, so it is not difficult to change. We just haven't exposed the setting yet to the user. We will play around with it and possibly expose the setting for beta testers to play with in the next beta.