H.264 in Firefox Android

[Snippo]

I have been able to stream H.264 to the Firefox browser on the desktop using the following guide: http://www.rs-online.com/designspark/electronics/eng/blog/building-a-raspberry-pi-2-webrtc-camera

Since (I think) Firefox 37 the Android browser also supports the OpenH264 plugin so H.264 should be working in the Android browser. Using the test page of Mozilla (https://mozilla.github.io/webrtc-landing/pc_test.html) I can also successfully playback H.264 in the Android browser. However, when trying to play a H.264 stream from Janus it doesn't work. Janus displays the following:

[3983546895] There's a message for JANUS Streaming plugin [3983546895] There's a message for JANUS Streaming plugin [3983546895] Creating ICE agent (ICE Full mode, controlling) [3983546895] ICE send thread started... [3983546895] There's a message for JANUS Streaming plugin [3983546895] -- ICE Trickling is supported by the browser, waiting for remote candidates... [WARN] [3983546895] Still waiting for the DTLS stack for component 1 in stream 1... No more remote candidates for handle 3983546895! [3983546895] The DTLS handshake has been completed WebRTC media is now available [ERR] [ice.c:janus_ice_send_thread:2592] [3983546895] ... only sent -1 bytes? (was 1410)

The last line is repeated until everything freezes.

I have no clue why this is happening (or what is happening), so that is why I'm asking it here.

[saghul]

FWIW, I also had problems with Firefox 38 on the desktop, but the Developer Edition worked fine. Have you trued the beta? On May 16, 2015 17:14, "Snippo" notifications@github.com wrote:

I have been able to stream H.264 to the Firefox browser on the desktop using the following guide:

http://www.rs-online.com/designspark/electronics/eng/blog/building-a-raspberry-pi-2-webrtc-camera

Since (I think) Firefox 37 the Android browser also supports the OpenH264 plugin so H.264 should be working in the Android browser. Using the test page of Mozilla (https://mozilla.github.io/webrtc-landing/pc_test.html) I can also successfully playback H.264 in the Android browser. However, when trying to play a H.264 stream from Janus it doesn't work. Janus displays the following:

[3983546895] There's a message for JANUS Streaming plugin [3983546895] There's a message for JANUS Streaming plugin [3983546895] Creating ICE agent (ICE Full mode, controlling) [3983546895] ICE send thread started... [3983546895] There's a message for JANUS Streaming plugin [3983546895] -- ICE Trickling is supported by the browser, waiting for remote candidates... [WARN] [3983546895] Still waiting for the DTLS stack for component 1 in stream 1... No more remote candidates for handle 3983546895! [3983546895] The DTLS handshake has been completed WebRTC media is now available [ERR] [ice.c:janus_ice_send_thread:2592] [3983546895] ... only sent -1 bytes? (was 1410)

The last line is repeated until everything freezes.

I have no clue why this is happening (or what is happening), so that is why I'm asking it here.

— Reply to this email directly or view it on GitHub https://github.com/meetecho/janus-gateway/issues/237.

[Snippo]

I just tried the latest version of Aurora and that doesn't work either. The beta version for Android isn't updated yet. On the desktop it works on all versions afaik.

However, Janus doesn't crash when I open the stream in Aurora. It just won't display the video.

[ploxiln]

ICE / DTLS failure doesn't (well, shouldn't) have anything to do with h264. Does the same set-up work with the only change being a vp8 video source?

[lminiero]

As Pierce said, that doesn't look anything codec related. The error you say describes a failure by libnice to send the packet.

Incidentally, the packet seems dangerously close to the MTU in size, have you tried originating your media in smaller RTP chunks? IIRC there was a similar issue either here or on the group where the issue was fixed by having the H.264 encoder split in smaller pieces.

[Snippo]

I just tried it again. At first the browser would say that the stream started, but the video wasn't displayed. Now, it's stuck at "Starting, please wait..." and I get these messages in the log: [3709198950] ICE send thread started... [3709198950] There's a message for JANUS Streaming plugin [WARN] [3709198950] Skipping disabled/unsupported media line... [3709198950] -- ICE Trickling is supported by the browser, waiting for remote candidates... No more remote candidates for handle 3709198950!

So maybe the errors I got last week were just a coincidence. However, it still doesn't work. (I did enable media.peerconnection.video.h264_enabled by the way)

[lminiero]

Does this work in a different environment, e.g., on a Janus installed in your local network that you can reach directly? AFAIK Azure is not very WebRTC friendly, as you need to manually open tons of ports. My guess is that you're not even getting connectivity at all, again nothing that is related to H.264.

[Snippo]

Janus is installed on a Raspberry Pi on my local network. When accessed from a computer is works fine, but using Firefox on Android it won't work.

What do you mean with Azure? I forgot to mention last time that the VP8+Opus test stream works fine on Firefox for Android.

[lminiero]

Sorry, about Azure I must have considered input from another post/issue that mentioned that instead when replying to yours... apologies for the confusion! It's hard to keep track of all these messages without loosing a bit of my mind :-)

[lminiero]

Is it still an issue? Have you verified it's actually an issue in Janus and not in Firefox for Android instead?

[Snippo]

I also tested it in Firefox 39 and it is still not working. I have no clue which one is causing the issue. All I know is that the desktop version of Firefox works fine and the test page of Mozilla also works in the Android version. But not the Janus stream.

[roysjosh]

I have a problem that may be related. I have H.264 video only working from a RasPi 2 to Firefox 38 via janus. However, when I add in audio ICE fails. These are some lines from janus in debug mode:

[1544225562] Audio has NOT been negotiated, Video has been negotiated, SCTP/DataChannels have NOT been negotiated
[1544225562] The browser: supports BUNDLE, supports rtcp-mux, is doing Trickle ICE
[1544225562] Fingerprint (global) : sha-256 F9:41:C3:60:D3:B4:F6:8F:45:76:C3:22:9B:1A:47:BE:53:51:D4:C4:57:4A:18:88:F8:41:D0:95:4D:71:84:CA
[WARN] [1544225562] Skipping disabled/unsupported media line...
[1544225562] Parsing video candidates (stream=2)...
[1544225562] ICE pwd (local):     2c8df061e981d38a6e067a7c94c18433
[1544225562] ICE ufrag (local):   28aff07d
[1544225562] Video mid: video
[1544225562] DTLS setup (local):  active
[1544225562]   -- bundle is supported by the browser, getting rid of one of the RTP/RTCP components, if any...
[1544225562]   -- rtcp-mux is supported by the browser, getting rid of RTCP components, if any...
[1544225562] Audio disabled via SDP
[1544225562]   -- ICE Trickling is supported by the browser, waiting for remote candidates...
[...]
[1544225562] Trickle candidate (): candidate:0 1 UDP 2122187007 192.168.122.1 38989 typ host
[1544225562] Got a  candidate but we're bundling, ignoring...
[...]
[1544225562] Trickle candidate (): candidate:2 1 UDP 2122252543 192.168.1.234 59078 typ host
[1544225562] Got a  candidate but we're bundling, ignoring...
[...]
{"janus":"trickle","candidate":{"completed":true},"transaction":"qXo77QUEUjxr"}
No more remote candidates for handle 1544225562!

Watching traffic with tcpdump, janus on the RasPi2 never sends UDP to my laptop when audio is enabled as it seems that all remote (my laptop) candidates are ignored. This causes iptables to drop all UDP from my laptop to janus. With audio disabled, janus sends UDP to the candidate IP addresses from ICE which causes iptables to allow the UDP from my laptop.

I think this may be related to Firefox's recent implementation of the "Unified Plan" for multistream bundling; see https://hacks.mozilla.org/2015/03/webrtc-in-firefox-38-multistream-and-renegotiation/.

[lminiero]

You probably didn't configure the streaming mountpoint to listen for and negotiate audio. The default sample H.264 in the streaming plugin configuration only lists video.

[roysjosh]

[gstreamer-monitor-h264]
type = rtp
id = 2
description = H.264 live stream coming from gstreamer
audio = yes
video = yes
audioport = 8003
audiopt = 111
;audiortpmap = opus/48000/2
audiortpmap = opus/16000/1
videoport = 8005
videopt = 126
videortpmap = H264/90000
videofmtp = profile-level-id=42e01f\;packetization-mode=1
secret = adminpwd

[lminiero]

Opus is opus/48000/2 or nothing. https://tools.ietf.org/html/rfc7587#page-12

[roysjosh]

Ah, thanks. Solved. Sorry for the noise.

[marcin-sielski]

I have debugged this issue a little bit. I can confirm that h.264 stream cannot be seen on Android 5.x Nexus 7 although Firefox claims everything is fine in about:webrtc tab. Unfortunatelly adb logcat prints lot's of errors. Everything works fine on Android 4.1 on my other device.

[lminiero]

If this works on other devices and regular browsers, my guess is this is a device or client issue. Closing the issue here. Feel free to reopen if you find out additional info that point to a flaw in Janus instead.