GNOME Bugzilla – Bug 795044
webrtcbin: implement support for FEC and RTX
Last modified: 2018-06-27 14:54:51 UTC
Hopefully the code speaks for itself, this is a fixed up branch that was previously reviewed by Matthew some time ago now, I can put up the non-fixed-up branch somewhere if that is helpful
Created attachment 370619 [details] [review] webrtcbin: implement support for FEC and RTX
Review of attachment 370619 [details] [review]: All looks mostly sane :) It could do with some references to spec sections where possible for the fec/rtx things e.g. how the sdp is intended to be constructed.
Created attachment 371671 [details] [review] webrtcbin: implement support for FEC and RTX
Review of attachment 371671 [details] [review]: Looks good!
Attachment 371671 [details] pushed as 5c450c5 - webrtcbin: implement support for FEC and RTX
*** Bug 795939 has been marked as a duplicate of this bug. ***
After this fix chrome and firefox now fails to create send parameters. Though the "correct" parameters are sent from gstreamer, chrome/firefox doesn't think it can do it. Spoofing now seems to be the only option to keep browsers happy like my previous workaround
Two things: 1. Chrome seems to insist on constrained-baseline profile IDs. Just baseline won't work. 2. In newer Chrome versions, the fmtp line also needs to include "packetization-mode=1" : shorturl.at/kvyZ3 I'll update the demo soon accordingly.
(In reply to Carlos Rafael Giani from comment #8) > Two things: > > 1. Chrome seems to insist on constrained-baseline profile IDs. Just baseline > won't work. > 2. In newer Chrome versions, the fmtp line also needs to include > "packetization-mode=1" : shorturl.at/kvyZ3 > > I'll update the demo soon accordingly. Thanks. Even though they insist, it works when spoofing. They should really base their sdp on the actual capability of the system.
(In reply to Carlos Rafael Giani from comment #8) > Two things: > > 1. Chrome seems to insist on constrained-baseline profile IDs. Just baseline > won't work. > 2. In newer Chrome versions, the fmtp line also needs to include > "packetization-mode=1" : shorturl.at/kvyZ3 > > I'll update the demo soon accordingly. Hey, I'm missing some context here, by "demo" do you mean https://github.com/centricular/gstwebrtc-demos/commits/master? Is there something that needs to be added in webrtcbin to deal with these newer chrome versions? If so, can you open a new issue for this?
(In reply to Mathieu Duponchelle from comment #10) > > Hey, I'm missing some context here, by "demo" do you mean > https://github.com/centricular/gstwebrtc-demos/commits/master? > > Is there something that needs to be added in webrtcbin to deal with these > newer chrome versions? If so, can you open a new issue for this? I am referring to the demo code I attached to https://bugzilla.gnome.org/show_bug.cgi?id=795404 . My comment was actually meant for that bug. Somehow I landed here instead.
* i've applied https://bugzilla.gnome.org/attachment.cgi?id=371671 * i'm listening to object-signal::on-new-transceiver and there set the fec-type, GST_WEBRTC_FEC_TYPE_ULP_RED. * in object-signal::on-negotiation-needed i set fec-type=GST_WEBRTC_FEC_TYPE_ULP_RED and fec-percentage=100 for the 0st transceiver. this results in an SDP containing two extra streams a=rtpmap:102 red/90000 a=rtpmap:104 ulpfec/90000 however, this triggers object-signal::pad-added on the two extra rtp streams for red und ulpfec and i'm not sure how to handle them application-wise.
Cherry-picked to 1.14 as 8a73228 so people can use it, and because it along the way it adds support for the fmtp SDP attribute, that makes H.264 streaming work to Chrome and Safari.