-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
h264 codec not working any more in videoroom with chrome+firefox #2200
Comments
You now need to force an H.264 profile that will be universally supported across browsers, and we've found the Constrained Baseline Profile (CPB) works well in that regard. When you're creating the room, set it up with these additional parameters: 'videocodec': 'h264', 'h264_profile': '42e01f' This will force it to use the CBP profile for new rooms that you're creating. You may also want to recycle the Janus service so that any existing rooms are discarded. |
Ok, thanks. When I add the h264_profile it works with the videoroom.html test. However, in our code it isn't working in firefox...janus says the h264 codec isn't found in the SDP, even though it is. The janus_sdp_get_codec_pt_full function assumes that the extmap comes after the rtpmap, and it breaks if they are the other way around. In our code we are connecting to janus before publishing our feed, and that seems to reverse the order of the extmap and rtpmap from firefox in the SDP. |
Actually you don't really need to FORCE anything. Since we now support codec profiles, if you're using H.264 and don't specify any profile to use we'll just pick the first "flavour" of H.264 we find, which might be a profile other endpoints are not ok with. Not sure what you mean about |
Well, the videoroomtest.html in master definitely doesn't work between chrome and firefox if you specify h264 without any profile. As for janus_sdp_get_codec_pt_full: yes, I meant fmtp. It does iterate over each line, but once it gets the rtpmap line it sets check_profile to TRUE. Then it waits until it gets an fmtp line for that codec. If there are no more fmtp lines after it gets the codec, it returns false. It fails when processing this SDP (I've just copied the fmtp and rtpmap lines for brevity): a=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1 |
That's a thing that won't be easy to fix, and will probably require a couple of iterations (get rtpmap first, then get fmtp). I don't have time right now, too busy on other things, so pull requests are welcome. |
Yes, I'll try to do this in the next day or two. Looks reasonably straightforward, with a few possible ways of implementing it. |
Thanks! |
Ok, I've implemented a simple fix for this (setting a separate variable when we see an extmap if it matches the profile we're looking for, in addition to the current behaviour), and it seems work well. Will push a pull request once I've tested it more. It doesn't fix the issue of it not working between chrome and firefox if no h264 profile is set, but as long as you set an h264 profile for the room (which does seem to be required now), everything works perfectly now after applying this fix. |
Pull request here: #2212 |
Merged, so I'll close this. |
Sorry for posting on a closed thread but i didn't want to open a new thread for aprox the same issue. It works if you define the video codec profile (h264_profile) in the janus.plugin.videoroom.jcfg, BUT, if you want to create the room dynamically through the API there is no way to pass the video codec profile to be used. Is there any way to also make it available in the API so you can send the h264_profile "42e01f" through the API? Andrei |
You can add the h264_profile to the "create" message. (We do this, and it works). |
Tested in latest master:
videocodec = "h264"
Firefox is showing "no remote video available" from chrome. Works fine with chrome/chrome and firefox/firefox.
No problem in 0.9.5 branch, but problem starts in 0.10.0. I've spent some time trying to figure out which change caused the issue, but haven't narrowed it down to anything.
The text was updated successfully, but these errors were encountered: