Webrtc on Android stock browser not working

Discussion in 'Web Call Server 5' started by SLM, Aug 2, 2017.

  1. SLM

    SLM Member

    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.
    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 ?
  2. Max

    Max Administrator Staff Member

    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.
    Currently we don't state minimal version and we suppose that latest available version or about is installed.
    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.
    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:
    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:
    Drag and drop WSPlayer checkbox to first top place.

    Attached Files:

  3. SLM

    SLM Member

    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?

    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.

    I will look into this, thanks.
  4. Max

    Max Administrator Staff Member

    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
    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
  5. Max

    Max Administrator Staff Member

    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.
    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.
  6. SLM

    SLM Member

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

    SLM Member

    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.
  8. Max

    Max Administrator Staff Member

    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.
  9. SLM

    SLM Member

    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")
  10. Max

    Max Administrator Staff Member

    Please check our default player sample:
    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) {
            document.getElementById(stream.id()).addEventListener('playing', function(event){

    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:
    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.

Share This Page