Since testing Mediasoup, Chrome has started failing to play subscriber videos when part of a group call on a fresh page load. I’ve found that it’s because on a refresh, the subscriber streams are delivered before the publisher stream is established and so Chrome doesn’t let it pass the Mediastream checks for autoplay.
Can you please add a API call that starts publisher Mediastream capture before subscriber streams are delivered? This needs to be a defined call/option as opposed to standard as sometimes receiving subscriber streams with a play button is preferred.
Many thanks,
James
If you are right, then this cannot have anything to do with mediasoup. If you think that sometimes the order in which Subscribers or Publishers initialize their video playback determine whether the browser accepts the autoplay or not, then you will have this problem with mediasoup, Kurento, Jitsi or any other SFU. It is a browser related issue, not a server one.
I mean, developers have always been able to start users that only receive video, and that do not publish any stream at all (without providing access to mic and webcam).
I’m not saying it’s because of Mediasoup directly, but because it delivers streams so much quicker than Kurento that I’ve never seen it before. The Kurento streams always arrive after the publisher has started capturing and so Chrome is happy that it’s a bidrectional call.
I’ve done a quick hack for each video element created:
setTimeout(function() {
this.play();
}.bind(video),2000);
You say that developers have always been able to start receive only users. How do they do that when Chrome prevents autoplay unless muted, with a publish stream or with a high MEI. For all my receive only streams I put a play button on top with a click action to play, and if it detects autoplay success with high MEI then it disappears automatically.
Autoplay policies are browser dependant. Chrome doesn’t have to behave the same way as Firefox or Safari. Either way, I think openvidu-browser cannot include a MediaStream initialization on its own just to make sure that subscribers are able to autoplay. That is responsability of the application, as autoplay with audio may be a usual behavior, but shouldn’t be mandatory.
Just control the order of starts publisher Mediastream capture before subscriber streams are delivered on your own application.
Regards.
Yes, and Chrome is a pain for it.
It’s a shame you’re not more keen to look into this. I have made it work in the application but it seems like a hack. In a basic group video call using openvidu-browser with the new speed of Mediasoup, it’s likely that the first subscriber streams will arrive before capture starts properly leaving subscriber feeds not autoplaying which would be the expected behaviour. I fully accept that autoplay should never be taken for granted, a huge amount of my work has been to work around this, but this new circumstance I feel warrants further investigation.
@basicmonkey can you please share a minimal example where the issue is reproduced?
It is reproduced with the official tutorials presented in OpenVidu documentation?
We will think if we can implement some general enough strategy to solve the issue without assuming any specific application. Or at least document the possible solutions properly in the documentation.
Regards
Thanks Micael. I’m really stretched trying to get a project finished and working but will happily look at some basic examples once it’s done.
Mediasoup really seems to be a great option, so much faster. Does mean you need to think more about stuff like this!