Video Posters don't play every time, leaving black planes
Closed this issue · 22 comments
Here is the video what I experience most of the time at my laptop.
The third video seems to be playable in 99%, all others randomly (play or not play).
Sometimes the same problems happen on iMac too.
The main downside is that after the first unsuccesful playing the main sound will be muted until a user would manage somehow to play any video poster (if he will be lucky), or reload.
bandicam.2021-05-04.02-18-01-148.mp4
Could it be a buffering issue? if you wait long enough do they play? would be interesting to check network inspector see what it's doing
If I wait some time the situation could be better but there is no direct dependency.
This video is always OK (but it is the only one)
So which branch is that? I don't see any of these.
This is main but one needs to copy poster data from ara.config.js to his own config.
Andrei it seems you have streaming issue. CTRL+SHIFT+I and open network tab, and then click on the picture. You will probably see red lines marked (failed) after a while. Or just wait long enough...
(works for me)
Here is the picture
Loading time is really too big, but there are not red lines or any other errors.
The same problem (much less ofter) happens at our iMac too (in the same local network), so it seems to be related with some streaming/networking/provider issue.
For some reasons the last video file is always plays OK, while others are more like lottery.
In some future I will try to add some condition to be sure that the file is really fully loaded, and see if it will help.
( texture.isReady didn't help).
Here is network data for screen videos (much better loading time, which may be related to the type):
Well that's the catch, it needs to start playing before it's fully loaded, that's the point of streaming. But then next time you click on it, it loads again.
The way you can try these red lines is to turn off your network access, and then click on the video and watch the network tab., this was the only way I could somewhat reproduce that behavior, i.e. stop videos from loading.
I suppose video posters worked well for you when you took these screenshots?
Please take screenshots just like these once you encounter issues.
I added some console logs to customizer.js
And what I've got after this:
bandicam.2021-05-07.21-58-22-904.mp4
Seems that the main reason of the black planes is the video is paused just after beginning of the playing.
Setting timeout 4500 solves the problem (at least in my case)
Here is the branch with corrected timeout - https://github.com/SoundStageFM/soundstage-vr/tree/video-poster-timeout-fix
Let me know if it doesn't create other problems :)
Probably timeout time should correspond to some parameter (to be bigger in my case) but I still cannot guess what it could be.
Well I just can't reproduce it.
BTW, why aren't we just autoplaying video texture?
Now I discovered another issue, caused by cloning mesh:
videoPoster = pickedMesh.clone("videoPoster-" + pickedMesh.name)
rvHJuCkh4e.mp4
This is caused by two meshes having exactly the same position, textures overlap in undefined manner (consequence of floating point arithmetic). I get the same behavior for all videos on that wall.
General solution is to have cloned mesh moved, say, 1cm towards the viewer.
This worked fine for me last time I checked, how's this working for you guys?
I am not sure that I have this effect or it is just video as it is.
I remember that in the first versions of video posters implementation I had no problems with video (I believe it was before 'pause' function insertion).
We can also hide original mesh since we don't need them both at one time (visibility = 0 or isVisible = false) and then (after playing video) show them again.
I see we also have serious FPS drop when video is starting; probably lower video resolution would be better for FPS and still have the same visual quality.
I admit the poster stuff isn't ironclad. It's an MVP right now, it works as best as I could get it to. Truth is I struggled quite a bit with them.
With autoplay they would start playing fine but then I experienced other challenges because the way some of the video events fire was not as expected, and it made it difficult to sort out what was going on and get the logic worked out.
This entire poster system does warrant a revisit/rewrite, and I imagine a class of it's own.
Although it's not a top priority right now, I would not object to proposals for trying to fix/rewrite it.
@jalmasi if this is something you would like to tackle this week I'm happy to leave it in your capable hands :)
No worries, lets see what else needs to be done.
Ah other events like 'paused", right?
Maybe we'd be better off without paused event, maybe just track click and ended event.
@eldinor yes hiding original poster is better, plus maybe we could do that once video starts playing
Well yes, but they need to click or move to pause the video, so we need not listen to 'pause' event.
@eldinor please see how it works for you now.
I can't reproduce it so I'm trying an educated guess. The change is minimal, just utilizing autoplay, hopefully video starts when ready. Guessing that in your case 1.5 sec wasn't enough to load, so it couldn't play.
At which commit is this change begins?
(cannot find) :)
At which commit is this change begins?
(cannot find) :)
ah, oops :) Just pushed, autoplay for video posters
Now it works without any problems :)
Closing the issue.