Set WebRTC video codec H.264 profile-level-id
to 42e01f
to be compatible with Firefox clients
#109
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
With
NEKO_VP8: 'false'
,NEKO_VP9: 'false'
andNEKO_H264: 'true'
underdocker-compose.yaml
'senvironment
tag, the video stream would be encoded in H.264 for WebRTC.But in
server/internal/webrtc/webrtc.go
, with the currentprofile-level-id=42001f
, Firefox 94.0.2 (on the client-side) won't accept the WebRTC video stream:https://github.com/m1k1o/neko/blame/c97b1fc4541caabf6b00331d081b02d2f9c58751/server/internal/webrtc/webrtc.go#L318
The symptom is that Firefox client displays a "Disconnected - connection timeout" message (after waiting for 15s) on the top left corner when logging in (despite entering the correct password). (Chrome works just fine btw.)
In the mean time, the following is found in the container log:
Also in Firefox
about:webrtc
, it shows only the audio track is accepted (recvonly
) but the video track is not (inactive
). This should further indicate the video (codec) provided by the server is not accepted:For reference, in
Remote SDP (Offer)
, we can see that H.264profile-level-id=42001f
is offered by the neko server in this case (but not accepted by the Firefox client):The Fix
I simply changed the
profile-level-id
from42001f
to42e01f
. Now it works flawlessly in both Firefox and Chrome.(Tested with
./build
then./build firefox
under.docker
. Reployed the neko container withdocker-compose up
.)Now Firefox client's
about:webrtc
shows that both video and audio tracks are accepted:Note that Chrome (96.0.4664.55)'s WebRTC implementation would accept H.264 stream with either
profile-level-id=42e01f
orprofile-level-id=42001f
without a problem. Maybe Chrome works with both profiles, or it just doesn't care about such (constraint flag) difference inprofile-level-id
.What's the catch (of changing
profile-level-id
in this case)?tl;dr: It should be fine. If any compatibility issues (with the decoder) are discovered on some other devices down the road, we could just explicit set the encoder profile to Constrained Baseline on the server side.
profile-level-id=42001f
indicates a Baseline profile, while42e01f
indicates a Constrained Baseline profile. (See the section below for how this is deducted.)According to Wikipedia:
42e01f
working but42001f
not working for the Firefox client should indicate that the Firefox WebRTC implementation only supports Constrained Baseline Profile (for whatever reason). (But the video decoder it eventually uses may well support both Constrained Baseline Profile and Baseline Profile, or even Main, Extended and High, which I haven't looked deep into.)On the encoder (server) side, as far as I have looked into the code base, neko uses
x264enc
whenopenh264
plugin is not installed. And indeed it usesx264enc
in my testing. From the container log again:The profile isn't explicitly specified in the command line. I would guess either Baseline or Constrained. I tried to determine the actual profile the encoder uses. But no luck so far. (Skimmed the x264enc doc, tried
chrome://media-internals/
, WireShark capture RTP stream).Bonus: What does
profile-level-id=42e01f
even mean?According to RFC 6184: RTP Payload Format for H.264 Video
So
profile-level-id=42e01f
would translate into:Table 5 [2]:
References
https://stackoverflow.com/q/22960928
Section 7.4.2.1.1 "Sequence parameter set data semantics" in https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-H.264-201602-S!!PDF-E&type=items
Please kindly review. Thanks :)