This one is tough to cause on purpose. I have no idea when it happens or why but sometimes (pretty often) my VideoTexture will just speed through the video 10x faster than it should. It happens randomly, sometimes right in the beginning, sometimes it starts after its been playing for a moment. The video file has no sound, and is just video stream.
Interestingly this behavior has not occurred for me on iOS while I was testing with iPad.
I’ll follow up with a screen recording.
A page I built for a friend’s cub-scout pack has this problem: https://cubs.gl.ax/
The page is setup pretty much like the playground, so its a good simple reproduction of the bug.
I am wondering if it could be because the rendering is too slow and if kind of tries to get back to where it should be compared to time if anything else was slowing the video to play when it starts ?
I can not repro unfortunately locally so pretty much guessing only at this point.
This was shared mainly to be used with people’s mobile devices, and it seems like a coin flip if it will work for them or speed to the end. It is such a strange bug because of the inconsistency … I’m not even sure where to breakpoint or hook in order to debug it but I’ll keep digging when I have time.
From my understanding the video itself has hardware accelerated decoding by browser and is blit onto a canvas using drawImage then the canvas pixel buffer is read through getImageData call and finally I’m guessing it is stored in texture via texImage2D call.
I haven’t yet had time to actually debug this but that’s the only way I know how to get a texture of a video. I have no issues playing this video normally on a page, nor does three.js have a problem playing the same video as a texture.
But to answer your question, no I haven’t tried any others to compare yet. Could you explain your line of thinking? I can’t imagine it’s specific to the video but maybe you are right. When I’m finally out of a dev crunch it should free me up and I’ll hook babylon all over the place and see if I can figure out where this timing anomaly is starting.
Hey there @Nowayz just checking in if there’s anything we can help you with now no worries if you haven’t had the time to do your tests yet we’ll be here whenever you can
I took Buck Bunny video and encoding it in a similar way to the slide show video from the bug report. Just a note: I also encoded the original slide show video using FFMPEG.
So, I took ffmpeg and compressed buck bunny as such: no audio track, same resolution (960x720), same codec (H.264). I think the biggest difference is probably the length of the video and the fact that its full motion (not a slide show).
Conclusion: after testing on multiple devices, the issue of video getting stuck, and rapidly shooting to the end seems to be gone.
This result is more confusing than if it had behaved the same way in both cases and I lack any guess about what might be causing the issue on the original video file. So, at this stage I’m setting some breakpoints in an attempt to isolate where calls may be stalling or happening at the wrong interval.
If anybody has any ideas, I’ll be more than happy to follow a lead.
I just tested the buck bunny video again after waiting awhile before clicking on the screen to play the video and it seems to be frozen in the middle also. Since it’s a 9-minute clip, I’m wondering if the behavior I’m seeing in the original is still possible to cause but may be more difficult because of the length.
On initial bug report similar behavior occurs, where the video pauses then rapidly plays to the end.
I haven’t seen it fly to the end yet, but considering the clip is substantially longer it may just be a matter of time… (I’m leaving my tab open for 10+ minutes and will report whether it does actually happen the same way)
Probably the reason is that the framerate of your original video is 2 frames per second.
Try to use some usual video with standard framerate like 30 fps or so.
Ah, I checked the frame rate and you’re right. That must have been a residual of the frame rate from the original file, though I’m uncertain why the issue with the video pausing is occurring intermittently on both.
And it does seem you are correct about 30FPS behaving much more consistently, but I think the fact that the 2FPS video works sometimes but intermittently fails should still be considered a bug should it not (or maybe deserves a console warning since the behavior is weird, though I’m not sure if the video framerate is accessible from the API we have avaliable)?
In the meantime, I’ll just re-encode the slideshow clip with a higher framerate and see if that resolves the issues.
no worries if you haven’t had the time to do your tests yet we’ll be here whenever you can