h264 streaming not working in chrome and safari

[Andrew Farmer]

I've been trying to get h264 streaming to work. I've started with the default Janus sample config files. The only change I made is to comment in the "h264-sample" in janus.plugin.streaming.cfg, then I run gstreamer.

The demo works on my Mac in Firefox. In Chrome and Safari I get no video, but also no error message in the logs.

The admin shows everything fine - state is "ready" and the out_stats are all increasing. The web UI even shows the bitrate, but no video.

I discovered that I can get the video to show up in Chrome by disabling hardware acceleration, as suggested by this bug:

https://bugs.chromium.org/p/webrtc/issues/detail?id=8420

However, that bug seems to indicate that the problem is only for the constrained baseline profile. I've tried modifying my gstreamer launch command to send main or high profile video with no luck.

Does h264 streaming work in Mac Chrome and/or Mac Safari for anyone else? I would especially expect it to work in Safari since I've heard h264 is the only profile supported there.

Appreciate any help,

Andrew

[Steve Hardt]

I have found that there are may inconsistencies between browsers and devices when using webRTC. One major issue is that Apple wants to do their own thing. WebRTC is supposed to support vp8, vp9, and h264 but apple only implemented h264. For IPads Safari works fine but webRTC is not supported in Chrome. On Android Chrome and Safari work fine but FireFox will not display video but play audio. On IPhone Safari is not playing the video. On Macs WebRTC works with Safari but not sure for chrome. On a PC, Chrome and Firefox work and you can get IE to work with a plugin but is not supported natively. 

I also convert my streams to HLS so I can play the stream on browsers/devices that have issues with WebRTC but that also bring another set of challenges that you need to address.

[Andrew Farmer]

Thanks for the reply - I've seen some of these headaches around the forum and I get that there is not consistent support, especially on mobile.

But I'd like to focus on desktop for this question. In fact, lets focus on Mac Safari. I can't even get that to work.

It sounds like a lot of people have h264 WebRTC streaming working in Mac Safari, isn't that right? I wonder why it doesn't work for me?

[Steve Hardt]

I use the video room and not the streaming plugin but if I had to venture to guess it that your videofmtp option may not be setup correctly as well as your h264 profile when sending your stream. 

Try videofmtp =profile-level-id=42e01f;packetization-mode=1 in your Janus streaming configuration. This is Baseline 3.1. Make sure you sending in that format also.

[Andrew Farmer]

My videofmtp value matches yours, I used this example config:

https://github.com/meetecho/janus-gateway/blob/master/conf/janus.plugin.streaming.cfg.sample.in#L123

But since you brought up videofmtp I noticed that my gstreamer command is printing out a different profile-level-id: 42c015

     caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, packetization-mode=(string)1, profile-level-id=(string)42c015

This is the gstreamer command that I'm using:

gst-launch-1.0 -v \

  videotestsrc \

  ! x264enc \

  ! video/x-h264, profile=baseline \

  ! rtph264pay config-interval=1 pt=96 \

  ! udpsink host=127.0.0.1 port=8004

So it looks like my issue is not really Janus related. Do you think that if I get gstreamer to produce profile 42e01f, it will show up in Safari? Do you know how I could do that or should I move over to a gstreamer forum?

Also right now I am just trying to get a test working so if you can recommend an alternative to gstreamer that would help as well (ffmpeg?)

[Steve Hardt]

I am not sure about gstreamer, I have never used it. So your doing Baseline 2.1. The profile and Level will depend on several factors like video size, bit rate, audio rate, frame rate and so on. So you will want to study up  a bit on that to make sure you set the profile correctly for what you are sending. You will also what to checkout what profiles IOS supports for h264.

[Lorenzo Miniero]

Just a quick note on videofmtp: when writing it in the configuration file, make sure you escape the semicolon, or everything after that will be stripped out (the semicolon is the character used for comments, in INI files), so something like this:

videofmtp = profile-level-id=42e01f\;packetization-mode=1

No need for the escape if you're passing videofmtp via plugin API instead.

L.

[Andrew Farmer]

Thanks for the extra info Lorenzo and thank you Steve for your help.

I ended up fixing the Chrome issue by switching from gstreamer to ffmpeg.

I tried getting gstreamer to use the correct profile (42e01f) but I wasn't able to make that happen. Then I switched to ffmpeg and Chrome was able to play anything that I sent regardless of profile: high, baseline, main, it all worked. So there is something about the stream produced by gstreamer that triggers an issue in Chrome.

It is also interesting that I can have things working in Chrome and Safari even if my videofmtp profile-level-id clearly does not match the profile that I'm using. 42e01f indicates a baseline profile but I was able to send main or high and still have it work.

I'm still having an issue with Mac Safari but I realized the symptoms of that issue are different. It is not a decoding issue. I'll look into it a bit more and possibly post a separate question on it.

In case it helps anyone else in the future, this is the ffmpeg command that I'm using to get an h264 stream working in both Mac Firefox and Mac Chrome. My input file is big buck bunny.

ffmpeg -re -i bbb_sunflower_1080p_30fps_normal.mp4 -vcodec libx264 -b:v 0.5M -an -f rtp rtp://127.0.0.1:8004

[Jonathan Martin]

Hi Andrew,

I'm the originator of the bug in https://bugs.chromium.org/p/webrtc/issues/detail?id=8420

I can confirm that the issue is also present with higher profiles, it's just that the only case I was covering with this bug was constrained baseline.

Recently, I found out that using the intel vaapi h264 encoder was working correctly while with x264enc it's still failing even now... There is something that Chrome on Mac does not like from that encoder, but since I raised the bug there is no interest into investigating this from chromium team :-(

Cheers

Jonathan