WebRTC video / audio stream in mobile browser will not play in background like a normal video

[Joseph Thompson]

I've built a Raspberry Pi based baby monitor which allows any browser on the local network to make a WebRTC connection with the Pi to receive the video / audio stream. The stream is displaying in a  simple webpage inside of a video tag that looks like this:

<div class="panel-body" id="stream">
    <video class="rounded centered" id="remotevideo" width="100%" height="100%" playsinline controls muted></video>
</div>

This works fine, but on mobile devices (in either Firefox or Chrome for Android), the stream will only stay engaged if the screen remains on with the webpage and browser in the foreground.

Desired Behavior: If you lock the phone (tap the power button), press the home button, switch to a different app, or change browser tabs, the stream (i.e. the audio) should continue uninterrupted indefinitely.

Actual behavior: The audio continues to stream for about a minute and then the stream dies (I think the OS or browser is killing the process since that tab has moved in to the background?).

The desired behavior I described is a standard feature of these browsers, I just don't understand why it is not working with the live WebRTC stream. I've tried replacing the WebRTC stream with a test .mp4 file and this produces the desired behavior. e.g.

1. The video starts playing in chrome
2. Press the home button, the video / audio initially pauses
3. A new media notification is shown in my notifications tray where I can press play
4. Audio resumes indefinitely
   

Why are these two sources of video behaving differently? Is there a way to enable the backround play for my WebRTC audio? Is there some limitation of browsers that I dont understand?

P.S. My baby monitor is almost identical to this Janus Streaming Demo and you can see the same behavior there.

Also, someone on stack overflow mentioned it might be related to this Chrome bug. It sounds very familiar, but I experience this in Firefox as well, so im not sure if this is the culprit or not.

[Lorenzo Miniero]

I think that's what browsers on mobile phones do to save battery: not sure if there are workarounds. Anyway, those workarounds would need to happen on the client side, as it's not a problem in Janus.

L.

[Alessandro Amirante]

 I actually guess that the issue is caused by the signaling channel going down because no keep-alive messages are being sent when the phone goes to sleep or the browser is in background. If so, a (dirty) workaround might be to increase the session_timeout value in janus.jcfg or even disable it. In this latter case some procedure to cleanup zombie sessions should be also put in place of course.

A.

--
You received this message because you are subscribed to the Google Groups "meetecho-janus" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meetecho-janu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/meetecho-janus/715ab513-92f3-4818-aa33-41699cd1a488n%40googlegroups.com.

[Joseph Thompson]

Interesting idea, I'll try this out! I guess I really just want this to work overnight, so I could try setting it to 8 or 12 hours.

Question: Does closing out of the browser window / shutting down the browser send a "stop" signal to Janus? or would I have the Janus session  running for many hours after closing the web page?

Thanks!

- Joe

[Lorenzo Miniero]

It's up to you to send this stop message before the page closes, otherwise it's the session timeout that Alessandro mentioned that cleans up things. Check what our demos do for an example.

L.

[Joseph Thompson]

Thanks a bunch for the help, you two!

I tried just changing the session_timeout from 1 minute to 12 hours and it worked as expected (the stream would stay active all night with the screen sleeping). Note, the stream would still stop when the browser was in the background, but this probably has more to do with the OS or browser stopping the process.

Anyways, I did not implement any "clean up" like you recommended and eventually as you opened new Janus sessions throughout the day Janus eventually became unresponsive. So I will have to incorporate that some time in the future.

Thanks again for the help figuring that out!