VideoFrame is slow to respond to TimePosition property changes

Bug Reports Engine Bugs
#1

VideoFrame is slow to respond to TimePosition property changes as it can take noticeable amount of time to go by, before the frame is re-rendered to be at the updated TimePosition. I expect VideoFrame to respond immediately to TimePosition property change, in order to be consistent with the behavior that exists for the Sound and the AnimationTrack.

6 Likes
#2

Thanks for the report. We’ll follow up when we have an update for you;

3 Likes
#3

Is there any update on this? Still happening as of 3/15/2024

1 Like
#4

This bug makes creating seamless videoframes impossible, and it affects even singular videoframes as there will still be a delay. Can this bug please be fixed? I genuinely cannot continue my projects involving videoframes if it is broken.

2 Likes
#5

This is still a problem. It was causing issues when trying to make what younite is describing (playing separate videos seamlessly).

Additionally it seems as if .Ended and the TimeLength property aren’t accurate. I couldn’t figure out by how much exactly, but if you try to make videos play seamlessly like younite is describing using either that event or task.delay(timePosition) you will end up with a delay in between your videos like this:

If you try to update the TimePosition property before playing the video with some code like:

videoFrame.TimePosition = 0
videoFrame:Play()

…the VideoFrame will be slow to update the time position which causes a delay when trying to play the next clip. I’ve found in some cases it’s faster if you pause before updating it, but there are still delays.

With a few hacks (that should not be necessary), you can get it to play seamlessly like how younite described:

I open sourced the script and documented what I did to get it working: Seamlessly play multiple VideoFrames back to back · GitHub

Notably, the important workarounds are:

  1. Force each video to play and wait until videoFrame.IsLoaded to update before trying to play/load the next one
    • ContentProvider:PreloadAsync() should prevent this from being necessary but does not, however this is a separate problem. This is also an issue with ImageLabels that you try to preload, and a similar workaround is necessary (loading it onto a 1x1 ImageLabel).
  2. Play the next video 0.05 seconds before the current one finishes, because .Ended is late by a few frames and so is task.delay(timeLength)
  3. Update the TimePosition after hiding the VideoFrame instead of before you try to play. If you don’t, the bug described in the OP makes the delay even worse
  4. On the last clip you’re playing, hide the video early before playing the first clip since the ZIndex will be higher and cause another delay, since you’re probably relying on one of the methods from #2

It seems like :Pause() is also slow. In my code I’m pausing the VideoFrame, and then setting the TimePosition to 0 (in that order) and when I print the TimePosition before playing again, sometimes it would be 0.001…

The limitations to VideoFrames are a separate issue from the OP, but unfortunately none of what I’ve written about would be necessary if the VideoFrame limits were increased (3, 30 second videos per month on an ID verified account…???). Regardless the performance problems with VideoFrames that OP is describing are still a problem, and I think it affects more than just the TimePosition property. Hopefully this provided some helpful context :pray:

3 Likes
#6

Hi! We are currently looking into several ways to address this issue - I cannot promise an exact solution or timeline just yet.

You should be able to work around this issue at runtime by alternating the use of two or more VideoFrames with the “Video” property in a replicated location (I believe that’s what @unroot’s supplied solution does). Be sure to limit the number you use + unload the “Video” property when not in use for optimal performance.

If this does not work for what you’d like to do, please reach out and we can help investigate additional workarounds.

2 Likes
#7

Hi! Thanks for the thoughtful analysis and workaround. :pray:

Loading and playing VideoFrames on the client rather than the server should make their methods + events more accurate and responsive. If doing so still presents issues, please file a bug report so we can investigate.

ContentProvider:PreloadAsync() currently will not preload the whole video asset. We are currently investigating ways to make preloading a video more useful and intuitive w/o sacrificing developer intent and performance. Really appreciate the feedback on this.

4 Likes
#8

Thanks for the response! I appreciate the insight!

All of the testing I was doing was done from the client, none from the server. :Pause() wasn’t as slow as the delay in the video the OP posted (seems like ~1+ second) but closer to 0.001 seconds (since that’s what the TimePosition would be when printing it multiple seconds after pausing). The issues with .Ended and TimeLength also were on the client, but seemed to have a larger delay. When I was trying to play the next video by relying solely on the Ended event there was a delay of ~0.25 seconds between the video ending and the event firing, so the next video needs to be played a few seconds early to work around this.

Is there an approximate number of VideoFrames you would recommend using at most?

#9

Thanks for the additional context! Would you be able to report this as a separate bug with repro steps + what you’ve observed? It helps us with tracking + sharing updates. We’ll investigate further and see what we can do.

For this specific workaround, I’d recommend as few VideoFrames as possible. Likely 2-3, but you could probably use more without a noticeable impact.

In a general sense, you should try to be selective with the quantity of VideoFrames with the “Video” property filled out with an asset ID.

1 Like