After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 795044 - webrtcbin: implement support for FEC and RTX
webrtcbin: implement support for FEC and RTX
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
unspecified
Other All
: Normal enhancement
: 1.14.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 795939 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2018-04-07 01:32 UTC by Mathieu Duponchelle
Modified: 2018-06-27 14:54 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
webrtcbin: implement support for FEC and RTX (55.54 KB, patch)
2018-04-07 01:32 UTC, Mathieu Duponchelle
none Details | Review
webrtcbin: implement support for FEC and RTX (55.94 KB, patch)
2018-05-04 13:28 UTC, Mathieu Duponchelle
committed Details | Review

Description Mathieu Duponchelle 2018-04-07 01:32:21 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
Comment 1 Mathieu Duponchelle 2018-04-07 01:32:28 UTC
Created attachment 370619 [details] [review]
webrtcbin: implement support for FEC and RTX
Comment 2 Matthew Waters (ystreet00) 2018-04-10 02:19:07 UTC
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.
Comment 3 Mathieu Duponchelle 2018-05-04 13:28:49 UTC
Created attachment 371671 [details] [review]
webrtcbin: implement support for FEC and RTX
Comment 4 Matthew Waters (ystreet00) 2018-05-09 02:13:26 UTC
Review of attachment 371671 [details] [review]:

Looks good!
Comment 5 Mathieu Duponchelle 2018-05-09 12:48:00 UTC
Attachment 371671 [details] pushed as 5c450c5 - webrtcbin: implement support for FEC and RTX
Comment 6 Sebastian Dröge (slomo) 2018-05-09 13:18:52 UTC
*** Bug 795939 has been marked as a duplicate of this bug. ***
Comment 7 Pieter Willem Jordaan 2018-05-09 19:44:32 UTC
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
Comment 8 Carlos Rafael Giani 2018-05-12 21:22:55 UTC
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.
Comment 9 Pieter Willem Jordaan 2018-05-12 21:27:44 UTC
(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.
Comment 10 Mathieu Duponchelle 2018-05-14 21:11:06 UTC
(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?
Comment 11 Carlos Rafael Giani 2018-05-17 15:46:43 UTC
(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.
Comment 12 Andreas Frisch 2018-05-24 09:58:18 UTC
* 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.
Comment 13 Jan Schmidt 2018-06-27 14:54:51 UTC
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.