Webrtc on Android stock browser not working

[SLM]

Most stock browsers in Android do not display the webrtc stream. No errors client side and status server side always remain on Pending.
For example the stock browser on a Samsung Galaxy J3 is Chrome v55.0.2883.91.

The streaming session is created, and the stream will try to initialize but will not play and does not generate an error.
- SESSION_STATUS.CONNECTED
- SESSION_STATUS.ESTABLISHED
Whether or not the stream is active, it will NOT generate an error client side.

However, when you download a recent version of Chrome from the play store, it does work.

Even when I use the embedded player iframe code from the demo's, it doesn't work in the stock browser.

However, the stream DOES work when you try to play it in the HLS minimal player or in another HLS player, like this one: https://github.com/video-dev/hls.js. The delay in HLS streaming is significant however.

So my question is: why doesn't the normal player work in Chrome v55 (what is the minimal version needed for it to work?) because webrtc is (supposedly) supported in that browser and why isn't there an automatic fallback to HLS ?

 

[Max]

why doesn't the normal player work in Chrome v55 (what is the minimal version needed for it to work?) because webrtc is (supposedly) supported in that browser and why isn't there an automatic fallback to HLS ?

WebRTC API is being changed from version to version, that's why we use webrtc-adapter. The adapter is responsible for WebRTC API support in browsers and its versions.
So if a browser (supposedly) supports WebRTC, it does not mean it supports WebRTC equally in all versions of this browser.
Therefore it may do not work in older Chrome browsers. Our target is support of all latest stable WebRTC browsers. Thus it works in latest Chrome 60 but may do not work in Chrome 55.

what is the minimal version needed for it to work?

Currently we don't state minimal version and we suppose that latest available version or about is installed.

why isn't there an automatic fallback to HLS ?

Fallback is currently based on browser capabilities.
If browser states WebRTC support (getUserMedia), we mark this browser as WebRTC capable and suppose it will play stream over WebRTC.
We do not detect if playback is really success.
So if you detect Chrome 55 (or other unsupported browser) you can issue fallback to HLS up your code decision.

The delay in HLS streaming is significant however.

You can try new technology Media Source Extensions. It works similarly with HLS but has much lower delay, 3-5 seconds.
There is article about MSE playback in our blog:
https://flashphoner.com/how-to-broa...source-extensions-via-the-websocket-protocol/
Though Can I Use says that it works starting from Chrome 59
Or you can try to switch to WSPlayer Media Provider
It should work in Chrome 55 with a low delay related HLS:
https://wcs5-eu.flashphoner.com/demo2/embed-player
Drag and drop WSPlayer checkbox to first top place.

 

[SLM]

...
If browser states WebRTC support (getUserMedia), we mark this browser as WebRTC capable and suppose it will play stream over WebRTC.
We do not detect if playback is really success.

Well that IS pretty vital isn't it? And you do detect failure if the stream actually started and you do detect failure if the webrtc works but cannot find the stream, but the current javascript player just fails to detect whether or not stream.play() actually does something at all. When I look at the flashphoner javascript I can see a logger function. How do I activate this logger?

So if you detect Chrome 55 (or other unsupported browser) you can issue fallback to HLS up your code decision.

The problem with this approach is that it can be v55 or lower that doesn't work, or v56, v57, v58, or v59.0.0.x or lower that doesn't work or just some weird special version of chrome that doesn't work. I don't know and it wouldn't matter if only I were able to know if a stream plays or fails.

You can try new technology Media Source Extensions. It works similarly with HLS but has much lower delay, 3-5 seconds.
There is article about MSE playback in our blog:
https://flashphoner.com/how-to-broa...source-extensions-via-the-websocket-protocol/
Though Can I Use says that it works starting from Chrome 59
Or you can try to switch to WSPlayer Media Provider
It should work in Chrome 55 with a low delay related HLS:
https://wcs5-eu.flashphoner.com/demo2/embed-player
Drag and drop WSPlayer checkbox to first top place.

I will look into this, thanks.

 

[Max]

When I look at the flashphoner javascript I can see a logger function. How do I activate this logger?

On client
You can activate logger on API initialization:

Flashphoner.init({logger:{push:true, severity: "DEBUG"},...});

On server
You can enable extended logging in flashphoner.properties config

enable_extended_logging=true

With these two settings, WCS will keep browser logs on server.
Folder example: /usr/local/FlashphonerWebCallServer-5.0.2369/logs/client_logs/2017-08-02/fdmmr8egur7iqkpkrdaf8atvge-11-32-25
So you will be able to read browser logs after disconnect.
Or you can see logs directly from Android Chrome console.

Please share client and server logs or send to logs@flashphoner.com
Perhaps it is something simple having a quick fix.

• /usr/local/FlashphonerWebCallServer/logs/server_logs/flashphoner.log
• /usr/local/FlashphonerWebCallServer/logs/client_logs/...
• /usr/local/FlashphonerWebCallServer/conf
• browser console logs

 

[Max]

but the current javascript player just fails to detect whether or not stream.play() actually does something at all

It looks like unexpected behavior. At least player should raise FAILED error. Please provide logs, we will check it.
We will also check Chrome 55, however it may take a time.

The problem with this approach is that it can be v55 or lower that doesn't work, or v56, v57, v58, or v59.0.0.x or lower that doesn't work or just some weird special version of chrome that doesn't work. I don't know and it wouldn't matter if only I were able to know if a stream plays or fails.

Got it.
Well, if player really does not indicate any errors, it looks like a bug.
We will try to reproduce similar issue on our end.

 

[SLM]

Thank you. I will activate the logger client and server side later today / tomorow and send you the results.

 

[SLM]

I have tested it today and have sent the logfiles to your email address. As you can you there isn't anything reported on the creation of the stream:

12:25:15 INFO webrtc - "Initialized"
12:25:15 INFO websocket - "Initialized"
12:25:15 INFO core - "Initialized"
12:25:20 DEBUG core - "Play stream androidstream"

The client report file is only created when I reload the player page on the android browser (after having waited a long time for the stream to start or to fail which didn't happen). Flashphoner.log is empty so I presume no stream is actually sent by the server to the client.

When I try to view the stream in another browser, it works fine.

I have also tested it at the demo site on flashphoner.com (stream 1234 at around 14:20 hours Amsterdam time) and this didn't work either in the stock browser.

 

[Max]

We have tested Moto G, Android 5.1, Сhrome 55.0.2883.84 (downloaded as apk) - playing, not reproduced.
Embed Player: WebRTC - playing.
Win 8.1: playing.
Trying to test on Samsung Galaxy J3 or another device in J-series with Chrome 55.

 

[SLM]

Using a newer version of the javascript engine now at least returns an error using the stock browser (which wasn't Chrome 55 as I said but 38).

The following error occurs: Unhandled promise rejection

As I've said before, I don't mind if your javascript player doesn't work for these old versions, I just need a trigger to handle such an event. With this promise rejection error I can now create an exception rule and redirect them to an HLS player (which does work though it has a 10sec delay), although it would be better if the javascript SDK handled this itself.

(btw, the stock browser I tested it on has this browser string: "Mozilla/5.0 (Linux; Android 5.1.1; SAMSUNG SM-J320FN Build/LMY47V) AppleWebKit/537.36 (KHTML, like Gecko) SamsungBrowser/3.5 Chrome/38.0.2125.102 Mobile Safari/537.36")

 

[Max]

Please check our default player sample:
https://wcs5-eu.flashphoner.com/client2/examples/demo/streaming/player/player.html
https://github.com/flashphoner/flas....0/examples/demo/streaming/player/player.html
https://github.com/flashphoner/flas...-2.0/examples/demo/streaming/player/player.js
When you press 'Play' you will see pre-loader animation as on the picture below:

The pre-loader will be hidden upon the internal 'playing' event:

stream = session.createStream(options).on(STREAM_STATUS.PLAYING, function(stream) {
        $("#preloader").show();
        document.getElementById(stream.id()).addEventListener('playing', function(event){
            $("#preloader").hide();
        });
...

https://github.com/flashphoner/flas...examples/demo/streaming/player/player.js#L135

Therefore, once you have the 'playing' event on video element, you can consider a stream as playing and working.
So you can setup a timer checking if stream is playing. If the timer check is failed in, i.e. 10 seconds after playback attempt stream.play(), it can be a trigger to fallback to another streaming technology like HLS.

Please note. These two events are logically different:

STREAM_STATUS.PLAYING

Means server-side is in PLAYING state. Playback session is established on server, and server is sending streaming data to client / browser.

document.getElementById(stream.id()).addEventListener('playing', function(event) {...});

Means client side is in playing state. Video element or canvas element is in playing state, decoding and rendering video frames. You have to use this second event triggering for fallback purpose.