[meta] Update libwebrtc to new stable branch 2H2020
Categories
(Core :: WebRTC, enhancement, P2)
Tracking
()
People
(Reporter: ng, Assigned: pehrsons)
References
(Depends on 12 open bugs, Blocks 17 open bugs, Regressed 5 open bugs)
Details
(Keywords: meta)
Crash Data
Attachments
(297 files, 46 obsolete files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
Bug 1654112 - Update USE_X11 to WEBRTC_USE_X11 like rest of libwebrtc, in desktop_capturer.cc. r?ng!
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
This bug tracks the work necessary for the next libwebrtc update (2H 2020).
Information needed to perform this update is documented at https://wiki.mozilla.org/Media/WebRTC/libwebrtc_Update_2H2020 .
The process is documented at https://wiki.mozilla.org/Media/WebRTC/libwebrtc_Update_Process .
Reporter | ||
Updated•4 years ago
|
Reporter | ||
Updated•4 years ago
|
Updated•4 years ago
|
Reporter | ||
Updated•4 years ago
|
Reporter | ||
Updated•4 years ago
|
Reporter | ||
Updated•4 years ago
|
Reporter | ||
Updated•4 years ago
|
Reporter | ||
Updated•4 years ago
|
Reporter | ||
Updated•4 years ago
|
Reporter | ||
Updated•4 years ago
|
Reporter | ||
Updated•4 years ago
|
Assignee | ||
Comment 2•4 years ago
|
||
This code comes from the rollup of previous local patches to upstream, see
https://hg.mozilla.org/mozilla-central/rev/c8e80efab6fb
Updated•4 years ago
|
Assignee | ||
Comment 3•4 years ago
|
||
This is needed to not regress stats. The milliseconds unit is more prevalent in
upstream stats code for timestamps.
Assignee | ||
Comment 4•4 years ago
|
||
This is similar to how it's already included for video send.
Assignee | ||
Comment 5•4 years ago
|
||
Assignee | ||
Comment 6•4 years ago
|
||
Assignee | ||
Comment 7•4 years ago
|
||
Assignee | ||
Comment 8•4 years ago
|
||
Assignee | ||
Comment 9•4 years ago
|
||
This switches those integrations to the new Call API, with AudioSendStream and
AudioReceiveStream as main API surface.
Assignee | ||
Comment 10•4 years ago
|
||
Assignee | ||
Comment 11•4 years ago
|
||
Assignee | ||
Comment 12•4 years ago
|
||
Assignee | ||
Comment 13•4 years ago
|
||
This will be used in PeerConnectionImpl for packetsReceived on the send side (from
rtcp).
Assignee | ||
Comment 14•4 years ago
|
||
For AudioConduit this patch:
- Uses correct threads per upstream, pending changes due to the threading model
update that's coming - Uses new upstream APIs for getting data for the stats
For VideoConduit this patch:
- Removes the stats polling 1-second timer on main thread
- Removes the internal stats classes for bridging stats between main and sts
threads - Uses correct threads for direct access per upstream's thread checkers, pending
changes due to the threading model
For PeerConnectionImpl and RTCRtpReceiver this patch:
- Manages thread access into conduits for thread safety
- Translates from the upstream Stats data models into our DOM data model
Assignee | ||
Comment 15•4 years ago
|
||
These fixes are made to reflect the current state of upstream.
Assignee | ||
Comment 16•4 years ago
|
||
This sets up our code for creating Call instances so that it works. A number of
things are left to do. Most notable fixing the threading model.
Until that is fixed we use main thread as a "worker" but this is not ideal.
It both leads to excessive work loads on main, and us having to set main as
"current" (using upstream's API for this) whenever we call into main from what
is meant to be the worker thread.
Assignee | ||
Comment 17•4 years ago
|
||
Assignee | ||
Comment 18•4 years ago
|
||
Assignee | ||
Comment 19•4 years ago
|
||
Doing this outside of the dtor, especially, removes the requirement of the
conduit having to be destroyed on the worker thread (main).
Not having threading requirements on the conduits' dtor means we can constify
conduit members everywhere, so this patch tries to do that, for added compiler
guarantees.
Assignee | ||
Comment 20•4 years ago
|
||
Assignee | ||
Comment 21•4 years ago
|
||
This assert was intended for when an input stream is started with processing on.
However, when an input stream is started with processing off, then later when
processing is turned on it triggers this assert because mSegment contains data
from InsertInGraph().
Depends on D102289
Assignee | ||
Comment 22•4 years ago
|
||
The new AudioProcessingImpl, and in particular AEC3 it seems, is more picky on
the ordering here. After an ApplyConfig() it needs ProcessStream() to properly
set up its internals. ProcessReverseStream sets off various asserts, for
instance because the processing sample rate is not divisible by 16k if
ProcessReverseStream() was fed 44.1k.
Assignee | ||
Comment 23•4 years ago
|
||
The input stream is not processed in passthrough, so we should skip feeding the
reverse stream too, to stay in sync.
Assignee | ||
Comment 24•4 years ago
|
||
Assignee | ||
Comment 25•4 years ago
|
||
Assignee | ||
Comment 26•4 years ago
|
||
This should also work with libwebrtc 64 currently in-tree.
Assignee | ||
Comment 27•4 years ago
|
||
This removes some prefs for things that are now unconfigurable, and adds some
others. This also re-works the plumbing for updating the config on the fly
through applyConstraints(). It is now simpler, with a single infallible call
to apply the new config.
Assignee | ||
Comment 28•4 years ago
|
||
Before this patch, if the data callback contained less data than was left over
from the last iteration, we'd skip iterating the graph again. The graph is
however is capable of 0-iterations.
This patch removes that optimization so that every data callback results in an
iteration.
This makes it easier to defer processing input data to the track processing
step, as is needed by the next patch in this stack, to keep input and output as
handed to AudioProcessing in sync as config changes are applied with
ControlMessages (in between input and output data notifications). With input
data processing deferred, ControlMessages are run first, then processing of
input data and last processing of output data.
Assignee | ||
Comment 29•4 years ago
|
||
These previously allowed a discontinuity at the beginning of the output stream.
This will no longer occur.
Assignee | ||
Comment 30•4 years ago
|
||
This is similar to the behavior prior to bug 1532898, which introduced telemetry
reporting every second. There's a bit of a difference in that we only report
data if we had collected some though the 1 second interval telemetry timer in
PeerConnectionCtx.
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 31•4 years ago
|
||
Assignee | ||
Comment 32•4 years ago
|
||
Assignee | ||
Comment 33•4 years ago
|
||
This patch uses mMutex to guarantee that the audio thread does not get things
pulled away from under its feet. When on the AudioProxyThread we allow blocking
the thread during negotiation. On the real audio thread we avoid blocking on
the mutex and return an error instead. This leads to us inserting silence --
which is fine since we're going through negotiation (call setup, teardown or
re-negotiation).
This also fixes the channel count when GetAudioFrame fails and we insert
silence, to use the same channel count as when we last appended real data. Since
changing the channel count can in the worst case cause a GraphDriver switch.
Assignee | ||
Comment 34•4 years ago
|
||
Assignee | ||
Comment 35•4 years ago
|
||
Prior to this patch, WebRtcCallWrapper would never clear the call instance,
meaning that it went away as the classes having references to WebRtcCallWrapper
also went away. These are mainly TransceiverImpl and PeerConnectionMedia. There
are other classes too, but these are the ones that have a strong-ref to
WebRtcCallWrapper and are cycle collected.
With the worker threads in libwebrtc now using our own TaskQueues on top of
our SharedThreadPool instances, the ownership model of the Call instances
becomes problematic.
On shutdown, xpcom-shutdown-threads happens before the cycle collector is shut
down.
xpcom-shutdown-threads will however, block shutdown until all SharedThreadPools
have been shut down.
If a TransceiverImpl sits around until shutdown it will only be destroyed
during cycle collector shutdown. And, alas, we reach a deadlock as we're stuck
in xpcom-shutdown-threads until that TransceiverImpl gets destroyed.
This patch decouples the Call instance lifetime from the cycle collector, and
avoids the shutdown hang.
Assignee | ||
Comment 36•4 years ago
|
||
This is especially prompted by a recurring task from libwebrtc that when run
will schedule itself again, which on a shut down TaskQueue will fail an assert.
The behavior with this patch better mirrors blink's behavior, and is what
libwebrtc expects.
Assignee | ||
Comment 37•4 years ago
|
||
Assignee | ||
Comment 38•4 years ago
|
||
This prepares VideoConduit for the decoder/encoder factory and its handling of
PluginID.
Assignee | ||
Comment 39•4 years ago
|
||
This hooks up VideoReceiveStream::Config with a decoder factory and
VideoSendStream::Config with both a bitrate allocator factory and an encoder
factory.
The factories are new and wraps all the types of decoders and encoders that we
could create prior to this patch. This patch lets libwebrtc create our codecs
on demand, allowing for reconfiguring the streams and changing codec on the fly.
Some extra care had to be taken to ensure that GMP PluginIDs can be properly
plumbed. This has been implemented with MediaEvent and MozPromise.
Some other changes are made too, as warranted by runtime or threading changes.
Assignee | ||
Comment 40•4 years ago
|
||
Assignee | ||
Comment 41•4 years ago
|
||
With the libwebrtc update codecs will be created off-main.
WebrtcGmpPCHandleSetter not only adds a lot of indirection, it is also
main-thread-only. With this patch we can create gmp codecs on any thread.
Assignee | ||
Comment 42•4 years ago
|
||
Assignee | ||
Comment 43•4 years ago
|
||
Assignee | ||
Comment 44•4 years ago
|
||
Comment 45•4 years ago
|
||
Updated•4 years ago
|
Assignee | ||
Comment 46•4 years ago
|
||
The RTPFragmentationHeader is gone. Instead the packetizer scans for NALU start
sequences. OpenH264 encodes them natively, but converts them to NALU sizes
as expected by GMP.
This patch puts the start sequences back in, in-place, and mitigates bug 1533001
by allowing the start sequences that leak through from OpenH264 straight through
to libwebrtc, as an audit of OpenH264 code shows this can happen when internally
OpenH264 reports a NAL count of 0.
Comment 47•4 years ago
|
||
Assignee | ||
Comment 48•4 years ago
|
||
Comment 49•4 years ago
|
||
Comment 50•4 years ago
|
||
Comment 51•4 years ago
|
||
Depends on D102953
Comment 52•4 years ago
|
||
Depends on D105009
Comment 53•4 years ago
|
||
Depends on D105010
Comment 54•4 years ago
|
||
Depends on D105011
Comment 55•4 years ago
|
||
Depends on D105012
Comment 56•4 years ago
|
||
Depends on D105013
Comment 57•4 years ago
|
||
- Pull in sdk/objc/base and sdk/objc/helpers
- Ensure that -fobjc-arc is set (have to use cflags, because our gn -> json scripting ignores things like cflags_objc)
- Add gclient_args.gni to keep build happy.
- Add a missing include path for libyuv
- Support .m files in build.
Depends on D105014
Comment 58•4 years ago
|
||
Depends on D105015
Comment 59•4 years ago
|
||
Depends on D105016
Comment 60•4 years ago
|
||
Depends on D105017
Comment 61•4 years ago
|
||
Depends on D105018
Comment 62•4 years ago
|
||
Depends on D105019
Assignee | ||
Comment 63•4 years ago
|
||
Assignee | ||
Comment 64•4 years ago
|
||
Assignee | ||
Comment 65•4 years ago
|
||
Assignee | ||
Comment 66•4 years ago
|
||
Assignee | ||
Comment 67•4 years ago
|
||
Peer connections are cleaned up on shutdown through an xpcom-shutdown observer.
It doesn't block shutdown throughout async operations.
webrtc::Call instances are currently used on the main thread and so destroying
them could be a sync operation. However with upcoming threading model changes
they are moving to a worker thread, making destruction of them inevitably async.
Currently they are even destroyed async, even though still on the main thread,
to better simulate the behavior we'd see with the threading model updated.
Destroying Call instances async can lead to a race between destroying all
TaskQueues tied to the Call instance, and reaching xpcom-shutdown-threads.
xpcom-shutdown-threads will shut down the thread pools backing the TaskQueues,
making future dispatches fail. We have asserts checking that dispatches always
succeed.
This patch adds a ShutdownBlocker to the Call wrapper, so progressing to
xpcom-shutdown-threads is blocked until Call instances are cleaned up and no
more dispatches are expected.
Assignee | ||
Comment 68•4 years ago
|
||
Assignee | ||
Comment 69•4 years ago
|
||
Assignee | ||
Comment 70•4 years ago
|
||
Assignee | ||
Comment 71•4 years ago
|
||
Assignee | ||
Comment 72•4 years ago
|
||
Assignee | ||
Comment 73•4 years ago
|
||
Assignee | ||
Comment 74•4 years ago
|
||
Comment 75•4 years ago
|
||
Comment 76•4 years ago
|
||
Comment 77•4 years ago
|
||
Comment 78•4 years ago
|
||
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 79•4 years ago
|
||
Assignee | ||
Comment 80•4 years ago
|
||
This helps with ASAN link errors. Cherry-picked commit's commit message:
310c82cd97b3f1f0d1ee93a0ee2b0aee828b2a93 by Abseil Team <absl-team@google.com>:
Simplify unaligned memory access functions.
The #ifdef to produce calls to __sanitizer_unaligned_load16 etc were needed in past versions of this code, when we were lying to the compiler about the alignment of the loads/stores, by using a reinterpret_cast.
However, a year ago, absl switched to simply use memcpy. Sanitizers support this correctly by default, nothing extra is required.
PiperOrigin-RevId: 343159883
Assignee | ||
Comment 81•4 years ago
|
||
This patch fixes a linker error where __sanitizer_annotate_contiguous_container
is an undefined hidden symbol referenced by
third_party/libwebrtc/third_party/abseil-cpp/absl/container/fixed_array.h.
Assignee | ||
Comment 82•4 years ago
|
||
Assignee | ||
Comment 83•4 years ago
|
||
Assignee | ||
Comment 84•4 years ago
|
||
Comment 85•4 years ago
|
||
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 86•4 years ago
|
||
Comment 87•4 years ago
|
||
Comment 88•4 years ago
|
||
Comment 89•4 years ago
|
||
Comment 90•4 years ago
|
||
Comment 91•4 years ago
|
||
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 92•4 years ago
|
||
Updated•4 years ago
|
Assignee | ||
Comment 93•4 years ago
|
||
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Reporter | ||
Comment 94•4 years ago
|
||
Reporter | ||
Comment 95•4 years ago
|
||
Depends on D107878
Reporter | ||
Comment 96•4 years ago
|
||
Depends on D107879
Reporter | ||
Comment 97•4 years ago
|
||
Depends on D107880
Reporter | ||
Comment 98•4 years ago
|
||
Upstreaming bug 1697385
Depends on D107881
Reporter | ||
Comment 99•4 years ago
|
||
Depends on D107897
Reporter | ||
Comment 100•4 years ago
|
||
Upstreaming bug 1697385
Depends on D107898
Reporter | ||
Comment 101•4 years ago
|
||
Depends on D107899
Reporter | ||
Comment 102•4 years ago
|
||
WIP Note: originally I commented this block out instead of checking build_with_mozilla. This needs to be checked.
Depends on D107900
Reporter | ||
Comment 103•4 years ago
|
||
Depends on D107901
Reporter | ||
Comment 104•4 years ago
|
||
Depends on D107902
Assignee | ||
Comment 105•4 years ago
|
||
Assignee | ||
Comment 106•4 years ago
|
||
Assignee | ||
Comment 107•4 years ago
|
||
This removes media/signaling/src from ThirdPartyPaths.txt as that directory no
longer exists.
It also adds media/signaling/gtest/MockCall.h as the new SetAndGetRecordingState
from upstream libwebrtc causes a static-analysis error because RecordingState is
a non-param type.
Assignee | ||
Comment 108•4 years ago
|
||
Reporter | ||
Comment 109•4 years ago
|
||
Depends on D107878
Reporter | ||
Comment 110•4 years ago
|
||
Depends on D108087
Reporter | ||
Comment 111•4 years ago
|
||
Comment 112•4 years ago
|
||
The cache can be a lot simpler than the old one, since libwebrtc handles
pruning old entries for us, and since we're now telling libwebrtc when we
render frames (so we don't have to make our own stats with guesses of when
frames will be rendered). We also now have a single implementation of the
cache in the base class.
This patch also removes the old CSRC stat insertion stuff we hacked into
libwebrtc for testing, and handles that stuff in our cache directly.
Comment 113•4 years ago
|
||
Involves teaching MediaPipelineFilter to learn ssrc->rid mappings more
aggressively since libwebrtc does not emit RTP RID more than once.
Also involves modifying a couple of mochitests to look for RTP RID in
the first packet, instead of whichever one comes in next once we care.
Comment 114•4 years ago
|
||
- Make sure this is 0 if we have not received a RTCP RR yet.
- Subtract the packet lost count from the result.
Comment 115•4 years ago
|
||
The divisor here was already in ticks/sec, which results in a conversion to seconds.
Comment 116•4 years ago
|
||
Comment 117•4 years ago
|
||
libwebrtc has stopped surfacing these, and Chromium does not support
these stats at all.
Comment 118•4 years ago
|
||
We've never supported the spec spelling (packetsDiscarded), and libwebrtc
no longer supports discarded packet count anyway.
Comment 119•4 years ago
|
||
Alsol, make sure errors note what kind of stats (audio/video) are being checked.
Comment 120•4 years ago
|
||
Updated•4 years ago
|
Comment 121•4 years ago
|
||
Comment 122•4 years ago
|
||
Comment 123•4 years ago
|
||
Comment 124•4 years ago
|
||
Updated•4 years ago
|
Assignee | ||
Comment 125•4 years ago
|
||
This makes the latest changes to base_capturer_pipewire in our tree compile
with the libwebrtc 86 update.
Comment 126•4 years ago
|
||
Comment 127•4 years ago
|
||
Comment 128•4 years ago
|
||
Reporter | ||
Comment 129•4 years ago
|
||
Reporter | ||
Comment 130•4 years ago
|
||
Depends on D107902
Reporter | ||
Comment 131•4 years ago
|
||
Depends on D110897
Reporter | ||
Comment 132•4 years ago
|
||
Depends on D110898
Reporter | ||
Comment 133•4 years ago
|
||
Depends on D110895
Reporter | ||
Comment 134•4 years ago
|
||
Depends on D111294
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Reporter | ||
Comment 135•4 years ago
|
||
This updates the previous revision: https://phabricator.services.mozilla.com/D107897 .
Reporter | ||
Comment 136•4 years ago
|
||
It turns out these were in a specific order. This restores the order from a previous patch.
Updated•4 years ago
|
Reporter | ||
Comment 137•4 years ago
|
||
Additionally:
- Trys to detect non-generated build file changes to the tree and exits to prevent a clean checkout and clobber
- Adds the DEBUG_GEN variable that prints what is happening in the script
- tee(s) the output of mach into the logs so one doesn't have to check them to see what went wrong
- Removes the symlinked directories if they were left over by a failed run
- Exits as soon as anything exits unexpectedly
- Adds an optional variable so that the git checkout and the
gclient sync
checkout can live in different locations
Reporter | ||
Comment 138•4 years ago
|
||
Depends on D112131
Reporter | ||
Comment 139•4 years ago
|
||
Depends on D112132
Updated•4 years ago
|
Assignee | ||
Comment 140•4 years ago
|
||
Assignee | ||
Comment 141•4 years ago
|
||
This patch also renames it WebrtcCallWrapper, to better match neighboring
classes starting on "Webrtc".
Assignee | ||
Comment 142•4 years ago
|
||
Ideally TaskQueueWrapper would implement both webrtc::TaskQueueBase and
AbstractThread, but webrtc::TaskQueueBase is not refcounted so implementing both
in the same class is not possible.
This patch implements AbstractThread in a refcounted class CallWorkerThread on
top of TaskQueueWrapper. Because of SharedModuleThread not having a thread-safe
refcount, the same CallWorkerThread must be used for all Call instances.
PeerConnectionCtx's SharedWebrtcState becomes the canonical owner of the
CallWorkerThread, but WebrtcCallWrappers will all hold a strong reference to it.
The new AbstractThread allows us to use webrtc TaskQueues with Mozilla
specific higher order threading functions, like MozPromise, MediaEventSource,
and whatever else could come in handy, without having to use an explicit
CurrentTaskQueueSetter (which is not public) everywhere.
Assignee | ||
Comment 143•4 years ago
|
||
Assignee | ||
Comment 144•4 years ago
|
||
Assignee | ||
Comment 145•4 years ago
|
||
Assignee | ||
Comment 146•4 years ago
|
||
Assignee | ||
Comment 147•4 years ago
|
||
Assignee | ||
Comment 148•4 years ago
|
||
Assignee | ||
Comment 149•4 years ago
|
||
Assignee | ||
Comment 150•4 years ago
|
||
Assignee | ||
Comment 151•4 years ago
|
||
This patch makes mediapipeline_unittest pass an event target to the Call wrapper
but keeps using main thread for that event target, so that it can keep the test
cases simpler by allowing sybnc calls into the conduits.
TaskQueueWrapper::MainAsCurrent is no longer needed as mediapipeline_unittest
was the last user of it. A simpler version remains dedicated in
mediapipeline_unittest instead.
Assignee | ||
Comment 152•4 years ago
|
||
On its own this patch should mainly be seen as a refactor of the way we handle
races in MediaPipelineTransmit::SetTrack. Namely that Stop() immediately
followed by SetTrack is still exposed to racing.
This patch makes MediaPipelines use a WatchManager to manage their tracks.
For receive pipelines, mActive triggers whether we enable the receive listener.
For transmit pipelines, mActive and mDomTrack triggers whether mDomTrack's
underlying track is hooked up to feed data to the conduit. A hole is also
punched through this allowing for unittests to set an overriden send track
to avoid mocking a MediaStreamTrack (DOM object) and MediaTrackGraph (several
non-virtual methods we'd need to override).
This patch also moves the responsibility of starting and stopping conduits to
the transceiver/receiver objects, where most of the interaction with the
conduits is already happening.
Assignee | ||
Comment 153•4 years ago
|
||
This patch mainly sets the stage for using codec configs with StateMirroring.
It also makes the code a bit simpler, and removes the need to handle the nullptr
case.
Assignee | ||
Comment 154•4 years ago
|
||
Assignee | ||
Comment 155•4 years ago
|
||
SharedWebrtcState when managed by PeerConnectionCtx is destroyed on main thread.
With interactions with call instances being async, there is no guarantee that
the objects owned by SharedWebrtcState (and referenced through raw pointers by
Call instances) are alive until all Call instances have been destroyed.
Making the WebrtcCallWrapper keep a strong-ref to the SharedWebrtcState will
ensure it can manage the lifetime of the SharedWebrtcState for as long as
necessary.
Assignee | ||
Comment 156•4 years ago
|
||
The logic used for choosing codec in this patch mimics the logic of Chromium.
Assignee | ||
Comment 157•4 years ago
|
||
Assignee | ||
Comment 158•4 years ago
|
||
Assignee | ||
Comment 159•4 years ago
|
||
The case added by this patch will be used to destroy the worker thread on
shutdown, and have it release its resources. In particular the reference to its
underlying thread pool, which could be blocking shutdown.
Unittests might still use the case where responsibility of destroying the worker
thread is left external, to allow using SharedWebrtcState with main thread as
the worker thread.
Assignee | ||
Comment 160•4 years ago
|
||
This patch makes the Call worker thread support tail dispatch, since it is
required for state mirroring. Since tail dispatch is only used when both the
source and target threads support it, this will only be used for dispatch to or
from other Mozilla threads.
TaskQueueWrappers created by libwebrtc are made to not support tail dispatch,
since upstream code assumes that dispatches are direct. In some places this is
seen by one webrtc::TaskQueue dispatching a task to another webrtc::TaskQueue
and blocks the source thread until the task has run on the target.
Assignee | ||
Comment 161•4 years ago
|
||
Assignee | ||
Comment 162•4 years ago
|
||
Assignee | ||
Comment 163•4 years ago
|
||
Assignee | ||
Comment 164•4 years ago
|
||
This patch makes AudioConduit mimic VideoConduit. We no longer do any
thread-specific actions in the dtor, so this assert is unnecessary.
Assignee | ||
Comment 165•4 years ago
|
||
With VideoConduit setters being called on a worker thread rather than main, we
no longer have a guarantee that the first SendVideoFrame comes in after ssrcs
or the send codec config are set.
Setters have so far been called on main, and the listener that triggers
SendVideoFrame is also managed by main. Using a call worker thread would change
the thread the setters run on, but not the SendVideoFrame triggering listener.
This breaks the guarantee.
Assignee | ||
Comment 166•4 years ago
|
||
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Comment 167•4 years ago
|
||
- Our build didn't like the non-explictness of these conversion
operators. - Changing to explicit required casts in various places.
Reporter | ||
Updated•4 years ago
|
Comment 168•4 years ago
|
||
Comment 169•4 years ago
|
||
Depends on D113433
Comment 170•4 years ago
|
||
Depends on D113434
Comment 171•4 years ago
|
||
Depends on D113435
Comment 172•4 years ago
|
||
Depends on D113436
Comment 173•4 years ago
|
||
Depends on D113437
Comment 174•4 years ago
|
||
Depends on D113438
Comment 175•4 years ago
|
||
- pipefail doesn't work in sh on linux, so we're running under bash now.
- removing a link for third_party/libwebrtc/.git didn't work due to a typo.
- needed export on MOZCONFIG line.
- only grab the specific .json file based on the build config.
Depends on D113439
Comment 176•4 years ago
|
||
Depends on D113440
Comment 177•4 years ago
|
||
Depends on D113441
Comment 178•4 years ago
|
||
Depends on D113442
Comment 179•4 years ago
|
||
Depends on D113443
Comment 180•4 years ago
|
||
Depends on D113444
Reporter | ||
Comment 181•4 years ago
|
||
Depends on D112133
Reporter | ||
Comment 182•4 years ago
|
||
Depends on D113604
Comment 183•4 years ago
|
||
Reporter | ||
Comment 184•4 years ago
|
||
Depends on D113605
Comment 185•4 years ago
|
||
Comment 186•4 years ago
|
||
Comment 187•4 years ago
|
||
Comment 188•4 years ago
|
||
Only works on Chrome because they zero out alloced memory?
Comment 189•4 years ago
|
||
Involves calling CFRunLoopRunInMode on the capture thread (so the RunLoop gets
cycles), and also calling Start() on the capture thread (so the callbacks are
connected to the same RunLoop we're giving cycles to).
Comment 190•4 years ago
|
||
Comment 191•4 years ago
|
||
Comment 192•4 years ago
|
||
Fixing error: format specifies type 'long' but the argument has type 'webrtc::ScreenId' (aka 'int')
Reporter | ||
Comment 193•4 years ago
|
||
Comment 194•4 years ago
|
||
Updated•4 years ago
|
Comment hidden (obsolete) |
Reporter | ||
Comment 196•4 years ago
|
||
Andrew, I do not believe any of the work in this bug has landed. There is still much work to be done. We are doing a number of try builds as we try to green this up.
Reporter | ||
Updated•4 years ago
|
Comment 197•4 years ago
|
||
Oops, I meant to post that in another bug. Sorry.
Reporter | ||
Comment 198•4 years ago
|
||
Reporter | ||
Comment 199•4 years ago
|
||
Reporter | ||
Comment 200•4 years ago
|
||
Depends on D115076
Updated•4 years ago
|
Updated•4 years ago
|
Reporter | ||
Comment 201•4 years ago
|
||
Depends on D115077
Comment 202•4 years ago
|
||
Comment 203•4 years ago
|
||
Updated•4 years ago
|
Comment 204•4 years ago
|
||
- Fix a couple typos.
- Add a CONFIG_DIR variable to short path references.
- Only run fixup_json.py on the current configs.
Comment 205•4 years ago
|
||
- Adds requirement to define an environment variable on linux
to indicate whether to generate only x86 files or x64/android
file. - Generating x86 files will require installing i386 versions of
some libraries in a bootstrapping type operation. - Generating x64/android files will run './mach bootstrap' to
restore the 64-bit library version installed for x86
generation. - Adds enviroment variable for skipping bootstrap operations
on linux.
Depends on D115642
Comment 206•4 years ago
|
||
Depends on D115643
Comment 207•4 years ago
|
||
Comment 208•4 years ago
|
||
Comment 209•4 years ago
|
||
Depends on D115652
Comment 210•4 years ago
|
||
Depends on D115653
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Reporter | ||
Comment 211•4 years ago
|
||
Depends on D115106
Reporter | ||
Comment 212•4 years ago
|
||
Depends on D115665
Reporter | ||
Comment 213•4 years ago
|
||
Depends on D115666
Reporter | ||
Comment 214•4 years ago
|
||
Depends on D115667
Reporter | ||
Comment 215•4 years ago
|
||
Depends on D115668
Comment 216•4 years ago
|
||
Comment 217•4 years ago
|
||
Depends on D115740
Comment 218•4 years ago
|
||
- new x86 linux json files
- updated linux/android json files
- updated macOS json files
Depends on D115741
Comment 219•4 years ago
|
||
Depends on D115742
Comment 220•4 years ago
|
||
These should all be permanent deletions unless we find
I've carved off too much of the abseil-cpp build.
Depends on D115742
Comment 221•3 years ago
|
||
Comment 222•3 years ago
|
||
Depends on D116252
Comment 223•3 years ago
|
||
Depends on D116253
Comment 224•3 years ago
|
||
Depends on D116254
Comment 225•3 years ago
|
||
Depends on D116255
Comment 226•3 years ago
|
||
Depends on D116256
Comment 227•3 years ago
|
||
Depends on D116258
Comment 228•3 years ago
|
||
Comment 229•3 years ago
|
||
Comment 230•3 years ago
|
||
Reporter | ||
Comment 231•3 years ago
|
||
Depends on D115667
Reporter | ||
Comment 232•3 years ago
|
||
Depends on D116552
Reporter | ||
Comment 233•3 years ago
|
||
Depends on D116553
Reporter | ||
Comment 234•3 years ago
|
||
Depends on D116554
Reporter | ||
Comment 235•3 years ago
|
||
Depends on D116555
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Comment 236•3 years ago
|
||
Comment 237•3 years ago
|
||
Comment 238•3 years ago
|
||
Depends on D116726
Comment 239•3 years ago
|
||
Comment 240•3 years ago
|
||
Depends on D116728
Comment 241•3 years ago
|
||
Comment 242•3 years ago
|
||
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Comment 243•3 years ago
|
||
Comment 244•3 years ago
|
||
Depends on D118050
Comment 245•3 years ago
|
||
Depends on D118051
Comment 246•3 years ago
|
||
Depends on D118052
Comment 247•3 years ago
|
||
Comment 248•3 years ago
|
||
Depends on D119412
Comment 249•3 years ago
|
||
Depends on D119413
Comment 250•3 years ago
|
||
Depends on D119414
Comment 251•3 years ago
|
||
Reporter | ||
Comment 252•3 years ago
|
||
Reporter | ||
Comment 253•3 years ago
|
||
Depends on D119702
Reporter | ||
Comment 254•3 years ago
|
||
Depends on D119703
Reporter | ||
Comment 255•3 years ago
|
||
Depends on D119704
Reporter | ||
Comment 256•3 years ago
|
||
Depends on D119705
Reporter | ||
Comment 257•3 years ago
|
||
This patch changes the meaning of the target architecture to mean what it nominally should according to the gn documentation. I question as to if this could be upstreamed, but it may be worth a shot. If we do choose to pursue that. There are several other smaller patches that tackle individual instances, that this could be combined with.
Depends on D119706
Reporter | ||
Comment 258•3 years ago
|
||
Depends on D119707
Reporter | ||
Comment 259•3 years ago
|
||
Reporter | ||
Comment 260•3 years ago
|
||
Depends on D119708
Reporter | ||
Comment 261•3 years ago
|
||
Depends on D119708
Reporter | ||
Comment 262•3 years ago
|
||
Depends on D120372
Reporter | ||
Comment 263•3 years ago
|
||
Depends on D120373
Reporter | ||
Comment 264•3 years ago
|
||
Depends on D120374
Reporter | ||
Comment 265•3 years ago
|
||
Depends on D120375
Reporter | ||
Comment 266•3 years ago
|
||
Depends on D120482
Reporter | ||
Comment 267•3 years ago
|
||
Depends on D120483
Reporter | ||
Comment 268•3 years ago
|
||
Depends on D120484
Reporter | ||
Comment 269•3 years ago
|
||
Depends on D120485
Reporter | ||
Comment 270•3 years ago
|
||
Comment 271•3 years ago
|
||
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Comment 272•3 years ago
|
||
Comment on attachment 9217237 [details]
Bug 1654112 - Allow using IsOnCurrentThread on AbstractThread. r?#xpcom-reviewers
Revision D112842 was moved to bug 1724867. Setting attachment 9217237 [details] to obsolete.
Assignee | ||
Comment 273•3 years ago
|
||
This patch also renames it WebrtcCallWrapper, to better match neighboring
classes starting on "Webrtc".
Assignee | ||
Comment 274•3 years ago
|
||
Ideally TaskQueueWrapper would implement both webrtc::TaskQueueBase and
AbstractThread, but webrtc::TaskQueueBase is not refcounted so implementing both
in the same class is not possible.
This patch implements AbstractThread in a refcounted class CallWorkerThread on
top of TaskQueueWrapper. Because of SharedModuleThread not having a thread-safe
refcount, the same CallWorkerThread must be used for all Call instances.
PeerConnectionCtx's SharedWebrtcState becomes the canonical owner of the
CallWorkerThread, but WebrtcCallWrappers will all hold a strong reference to it.
The new AbstractThread allows us to use webrtc TaskQueues with Mozilla
specific higher order threading functions, like MozPromise, MediaEventSource,
and whatever else could come in handy, without having to use an explicit
CurrentTaskQueueSetter (which is not public) everywhere.
Assignee | ||
Comment 275•3 years ago
|
||
Assignee | ||
Comment 276•3 years ago
|
||
Assignee | ||
Comment 277•3 years ago
|
||
Assignee | ||
Comment 278•3 years ago
|
||
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Assignee | ||
Comment 279•3 years ago
|
||
Prior to this patch we'd update the description when setting the dom track, but
that could end up attributing logs with a new track prematurely. This patch
fixes the timing of updating the description. It also accomodates override
tracks in the description.
Reporter | ||
Comment 280•3 years ago
|
||
Depends on D120930
Comment 281•3 years ago
|
||
Comment on attachment 9236046 [details]
Bug 1654112 - deliver each RTP or RTCP packet only once to the Call Receiver;r?bwc
Revision D122514 was moved to bug 1725739. Setting attachment 9236046 [details] to obsolete.
Updated•3 years ago
|
Updated•3 years ago
|
Comment 282•3 years ago
|
||
Comment 283•3 years ago
|
||
Depends on D123026
Comment 284•3 years ago
|
||
Depends on D123027
Assignee | ||
Comment 285•3 years ago
|
||
The main point of this patch is to harden how conduits handle configuration
changes. With conduit controller classes acting in a layer on top of conduits
(and their old sync style APIs), for instance
mTransmitting = true; mTransmitting = false;
on the control thread gets
elided and cannot be used as a mean of applying configuration changes in the way
StartTransmitting(); ChangeConfig(); StopTransmitting();
could.
This patch removes the conduit controller classes, instead moving their mirrors
directly into the conduits. This allows for one larger "ConfigChanged" method
which can apply all the config changes while being aware of the state of the
conduit.
This patch effectively moves from setters to mirrors.
Unittests are updated to work with the new async structure. They're only on main
thread, but updates still happen async. Some helpers ensure that state changes
and direct (tail dispatched) tasks run in a for the tests sync fashion.
Assignee | ||
Comment 286•3 years ago
|
||
Assignee | ||
Comment 287•3 years ago
|
||
Prior to this patch TransceiverImpl held a ref to the call wrapper until
destruction. The call wrapper has a const ref to the call thread, which sits on
top of a SharedThreadPool.
In a case where TransceiverImpl lived until CC shutdown we'd hang because
prior to CC shutdown we'd block until all thread pools were shut down, and
shutting down the call wrapper thread pool was in effect dependent on CC
shutdown.
Assignee | ||
Comment 288•3 years ago
|
||
Unclear why this path was missed in the original patch.
Hopefully I didn't outsmart myself.
Assignee | ||
Comment 289•3 years ago
|
||
source_tracker_ is thread safe with its own internal mutex, so this call is safe
as long as the caller has a guarantee for the lifetime of the
AudioReceiveStream. This is similar to webrtc::VideoReceiveStream.
Upliftable.
Assignee | ||
Comment 290•3 years ago
|
||
If js doesn't intend to look at get*Sources, then pushing RtpSource info to main
thread constantly is cycles spent in vain. Considering that upstream already
updates this info off-main on every received frame it is also to a large extent
duplicate work. Especially the dispatching from the real-time audio thread can
hurt audio performance, in the worst case causing discontinuities in the output
stream to a user's speakers.
With this patch we instead let the main thread js APIs call through to
upstream's record of the RtpSource info, as this happens to be thread safe
already. The result is cached on the main thread for the duration of the current
main thread task, to make us spec compliant, even though we don't follow the
spec to the letter ("When ... frame ... is delivered ... the UA MUST queue a
task to update the relevant information for the RTCRtpContributingSource and
RTCRtpSynchronizationSource dictionaries ...").
Updated•3 years ago
|
Assignee | ||
Comment 291•3 years ago
|
||
Assignee | ||
Comment 292•3 years ago
|
||
Assignee | ||
Comment 293•3 years ago
|
||
AudioConduit will try to grab the lock on the audio thread, and if it fails
there is a risk of glitching. That is fine as long as the only other usage of
the lock is related to renegotiation where the audio stream is being recreated
anyway.
Then GetRtpSources was added, which, in order to not have to continuously push
(every 10ms) data from the call thread to main, grabs the lock on main thread.
With a Mutex there is now a risk of glitching audio even when we are not in
renegotiation.
A Read-Write-Lock solves this, because only renegotiation would lock the write
lock.
Assignee | ||
Comment 294•3 years ago
|
||
This patch is the result of a latent race where in VideoConduit the SSRC first
gets set by STS upon receiving a packet (new order with the threading model
update). Through (partial) signaling the Call thread then sets it to 0, which
triggers generation of a new temporary SSRC. The STS thread sees this and skips
dequeing the packet queue, causing the packet queue to grab all incoming packets
and the call stalls.
Assignee | ||
Comment 295•3 years ago
|
||
This patch fixes a race where transports (through pipelines) would be detached
on the STS thread before conduits had finished shutting down on the call thread.
Conduits would send various packets during shutdown, for instance RTCP Bye.
Dropping these caused some test failures.
Assignee | ||
Comment 296•3 years ago
|
||
Assignee | ||
Comment 297•3 years ago
|
||
Assignee | ||
Comment 298•3 years ago
|
||
A deadlock may happen when main thread calls into a conduit's
GetUpstreamRtpSources() as it grabs the conduit lock, while at the same time a
platform codec may be blocked on a sync runnable to main in a stream start()
method.
We only lock to protect the m{Recv|Send}Stream members, so while needed around
deleting and creating streams, the lock is unnecessary when stopping and
starting them.
This patch refactors the conduits so that the lock is not held when stopping or
starting streams. It also cleans up some log messages and return codes - some
old failure modes no longer exist upstream.
Assignee | ||
Comment 299•3 years ago
|
||
Assignee | ||
Comment 300•3 years ago
|
||
Assignee | ||
Comment 301•3 years ago
|
||
Comment 302•3 years ago
|
||
- adds missing includes in several places
- makes dom/media/webrtc/jsapi unified-only
Reporter | ||
Comment 303•3 years ago
|
||
Updated•3 years ago
|
Assignee | ||
Comment 304•3 years ago
|
||
This is a cherry-pick of the patches in
https://bugs.chromium.org/p/webrtc/issues/detail?id=12529
It also removes the old custom code we had for these stats, and our integration
with them.
Assignee | ||
Comment 305•3 years ago
|
||
There are two problems with this stat:
- The BaseSeq tracking logic in MediaPipeline doesn't account for multiple ssrcs
(rtx) - The stats code in PCImpl queries the BaseSeq on the wrong thread (Call vs Sts)
This patch fixes both of these, by tracking BaseSeq per ssrc, and by introducing
an extra thread hop.
If it weren't for mediapipeline_unittest we could remove all the packet counting
in MediaPipeline. Doing that proper (with gmock?) is a patch for another day,
but this patch goes in this direction by also lifting out the BaseSeq logic to
the conduits.
Assignee | ||
Comment 306•3 years ago
|
||
Updated•3 years ago
|
Assignee | ||
Comment 307•3 years ago
|
||
Updated•3 years ago
|
Assignee | ||
Comment 308•3 years ago
|
||
The call thread TaskQueue is process global so more easily gets saturated than
the worker TaskQueues that are per-call. This shows for instance under rr and
tsan.
Comment 309•3 years ago
|
||
Assignee | ||
Comment 310•3 years ago
|
||
Comment 311•3 years ago
|
||
Reporter | ||
Comment 313•3 years ago
|
||
Assignee | ||
Comment 314•3 years ago
|
||
Updated•3 years ago
|
Updated•3 years ago
|
Reporter | ||
Comment 315•3 years ago
|
||
Reporter | ||
Comment 316•3 years ago
|
||
Updated•3 years ago
|
Reporter | ||
Comment 317•3 years ago
|
||
Updated•3 years ago
|
Reporter | ||
Comment 318•3 years ago
|
||
The PID was being recorded so we could avoid SCARY windows. This restores that code. We should
reevaluate the situation there. Perhaps the filtering is already available. I see at least a
hint of that.
Depends on D129097
Comment 319•3 years ago
|
||
This is a altered version of upstream's 78c73477c75f3262cad837ce7b46adf284166b14.
Reporter | ||
Comment 320•3 years ago
|
||
Updated•3 years ago
|
Updated•3 years ago
|
Assignee | ||
Comment 321•3 years ago
|
||
At one point these were part of upstream libwebrtc but have since been removed.
Since these are now effectively our code, we should keep them in
dom/media/systemservices/video_engine rather than adding them back into
libwebrtc with every update.
A later patch in this series will add them to the moz.build file and update the
desktop capture code to work with these in their new location.
Assignee | ||
Comment 322•3 years ago
|
||
Assignee | ||
Comment 323•3 years ago
|
||
Assignee | ||
Comment 324•3 years ago
|
||
Assignee | ||
Comment 325•3 years ago
|
||
Assignee | ||
Comment 326•3 years ago
|
||
Assignee | ||
Comment 327•3 years ago
|
||
Assignee | ||
Comment 328•3 years ago
|
||
Assignee | ||
Comment 329•3 years ago
|
||
The old options to set echo control level and routing mode have been removed.
There are now two gain controller implementations; this uses the original one,
investigating switching to the newer one is best left until we land the update.
Assignee | ||
Comment 330•3 years ago
|
||
Assignee | ||
Comment 331•3 years ago
|
||
This also disables the tests while we figure out the new API.
Assignee | ||
Comment 332•3 years ago
|
||
This also disables the gtests until we figure out the new API.
Assignee | ||
Comment 333•3 years ago
|
||
Assignee | ||
Comment 334•3 years ago
|
||
Assignee | ||
Comment 335•3 years ago
|
||
Assignee | ||
Comment 336•3 years ago
|
||
Assignee | ||
Comment 337•3 years ago
|
||
Assignee | ||
Comment 338•3 years ago
|
||
Assignee | ||
Comment 339•3 years ago
|
||
Assignee | ||
Comment 340•3 years ago
|
||
Upstream's implementation for rid and mid assumes they are always present but
the current code in MediaPipelineFilter had them optional. We need to double
check which way it should be.
Assignee | ||
Comment 341•3 years ago
|
||
Assignee | ||
Comment 342•3 years ago
|
||
Assignee | ||
Comment 343•3 years ago
|
||
Generating moz.build files from a mix of old and new gn generated json files
leads does not work, so we'll temporarily remove all of the old files.
Assignee | ||
Comment 344•3 years ago
|
||
Assignee | ||
Comment 345•3 years ago
|
||
Work around a chicken-and-egg problem while generating json files from gn.
Assignee | ||
Comment 346•3 years ago
|
||
Assignee | ||
Comment 347•3 years ago
|
||
These are basically header files, we can treat them as such.
Assignee | ||
Comment 348•3 years ago
|
||
Assignee | ||
Comment 349•3 years ago
|
||
Assignee | ||
Comment 350•3 years ago
|
||
Assignee | ||
Comment 351•3 years ago
|
||
Required because of merge errors when rebasing pipewire changes from our
current version of webrtc against similar pipewire changes upstream.
Assignee | ||
Comment 352•3 years ago
|
||
Assignee | ||
Comment 353•3 years ago
|
||
This needs some investigation to see why we get this warning when it is not
present upstream.
Assignee | ||
Comment 354•3 years ago
|
||
Assignee | ||
Comment 355•3 years ago
|
||
Assignee | ||
Comment 356•3 years ago
|
||
Assignee | ||
Comment 357•3 years ago
|
||
The Linux desktop capture code now relies on these. The build will fail at the
link stage if these are not in system header wrappers.
Assignee | ||
Comment 358•3 years ago
|
||
This enables more of the VideoConduit code and updates the APIs used.
Note that this removes REMB support (upstream has removed the corresponding
configuration and it appears that even in our current version of libwebrtc,
enabling REMB only affects logging.
This also removes configuring the keyframe request method, as this no longer
seems to be supported upstream.
We should probably double check both REMB and keyframe requests before
landing this code.
Comment 359•3 years ago
|
||
Comment on attachment 9198391 [details]
Bug 1654112 - Always start feeding input to audio processing, and always end on output.
Revision D102578 was moved to bug 1736481. Setting attachment 9198391 [details] to obsolete.
Comment 360•3 years ago
|
||
Comment 361•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/18a58105941b
https://hg.mozilla.org/mozilla-central/rev/4595917071a8
https://hg.mozilla.org/mozilla-central/rev/a93c2d1df066
https://hg.mozilla.org/mozilla-central/rev/d1df4970f4f0
https://hg.mozilla.org/mozilla-central/rev/587c40771588
https://hg.mozilla.org/mozilla-central/rev/d838dc7d2bb8
https://hg.mozilla.org/mozilla-central/rev/e67770bb6a49
https://hg.mozilla.org/mozilla-central/rev/9d7ab32fdc20
https://hg.mozilla.org/mozilla-central/rev/4c8284f52c8b
https://hg.mozilla.org/mozilla-central/rev/26f3fec64ff0
https://hg.mozilla.org/mozilla-central/rev/ae0715e32c27
https://hg.mozilla.org/mozilla-central/rev/3b777b313b76
https://hg.mozilla.org/mozilla-central/rev/3d1bbf5dddb0
https://hg.mozilla.org/mozilla-central/rev/1a244e507326
https://hg.mozilla.org/mozilla-central/rev/afe92bb8ee8e
https://hg.mozilla.org/mozilla-central/rev/03708238dc51
https://hg.mozilla.org/mozilla-central/rev/0dc6c152d8c6
https://hg.mozilla.org/mozilla-central/rev/e67874b7bab8
https://hg.mozilla.org/mozilla-central/rev/0aa9398df7c0
https://hg.mozilla.org/mozilla-central/rev/5288094fbef3
https://hg.mozilla.org/mozilla-central/rev/993f55a7c840
https://hg.mozilla.org/mozilla-central/rev/127ace4d8887
https://hg.mozilla.org/mozilla-central/rev/97e4dae7a466
https://hg.mozilla.org/mozilla-central/rev/069bf6604246
https://hg.mozilla.org/mozilla-central/rev/96f6051798d1
https://hg.mozilla.org/mozilla-central/rev/c055fdffd1d0
https://hg.mozilla.org/mozilla-central/rev/78ba9dd01553
https://hg.mozilla.org/mozilla-central/rev/9b6fd52d3ba8
https://hg.mozilla.org/mozilla-central/rev/7163801a480d
https://hg.mozilla.org/mozilla-central/rev/214c3af8fb37
https://hg.mozilla.org/mozilla-central/rev/92f0d3374bc9
https://hg.mozilla.org/mozilla-central/rev/6d34a9024dc2
https://hg.mozilla.org/mozilla-central/rev/8d832e832ffe
https://hg.mozilla.org/mozilla-central/rev/9452e226943f
https://hg.mozilla.org/mozilla-central/rev/57363f87bcb5
https://hg.mozilla.org/mozilla-central/rev/ef548d7758c7
https://hg.mozilla.org/mozilla-central/rev/99e7f86e5cad
https://hg.mozilla.org/mozilla-central/rev/c5502287708e
https://hg.mozilla.org/mozilla-central/rev/831bac499edc
https://hg.mozilla.org/mozilla-central/rev/35b22aad7def
https://hg.mozilla.org/mozilla-central/rev/d380a43d59f4
https://hg.mozilla.org/mozilla-central/rev/2b3390930a60
https://hg.mozilla.org/mozilla-central/rev/90a15d97399e
https://hg.mozilla.org/mozilla-central/rev/f16cf2573a4d
https://hg.mozilla.org/mozilla-central/rev/8d60ee1f7cd7
https://hg.mozilla.org/mozilla-central/rev/9b2bc72201da
https://hg.mozilla.org/mozilla-central/rev/93367fdd03ec
https://hg.mozilla.org/mozilla-central/rev/01b9c509cecf
https://hg.mozilla.org/mozilla-central/rev/f7e8157d3554
https://hg.mozilla.org/mozilla-central/rev/3eae9f9279f6
https://hg.mozilla.org/mozilla-central/rev/88a9fe04aaa5
https://hg.mozilla.org/mozilla-central/rev/06ae2b9a2703
https://hg.mozilla.org/mozilla-central/rev/069c5baf6d32
https://hg.mozilla.org/mozilla-central/rev/a55a718715f6
https://hg.mozilla.org/mozilla-central/rev/056b43129502
https://hg.mozilla.org/mozilla-central/rev/b5228352d20d
https://hg.mozilla.org/mozilla-central/rev/23b8f56eec4b
https://hg.mozilla.org/mozilla-central/rev/1af1af4020a2
https://hg.mozilla.org/mozilla-central/rev/4f5ac04b4f82
https://hg.mozilla.org/mozilla-central/rev/7e00d78d6389
https://hg.mozilla.org/mozilla-central/rev/c7dbdd82e8e8
https://hg.mozilla.org/mozilla-central/rev/a1c16b86d3a7
https://hg.mozilla.org/mozilla-central/rev/ceed49af0fad
https://hg.mozilla.org/mozilla-central/rev/da26bac32c32
https://hg.mozilla.org/mozilla-central/rev/675b46e5aba7
https://hg.mozilla.org/mozilla-central/rev/c8015b9110fd
https://hg.mozilla.org/mozilla-central/rev/6f33a2fcd373
https://hg.mozilla.org/mozilla-central/rev/d03b0978daf3
https://hg.mozilla.org/mozilla-central/rev/8eb021a434b0
https://hg.mozilla.org/mozilla-central/rev/b2f523bed588
https://hg.mozilla.org/mozilla-central/rev/59cad1af8e89
https://hg.mozilla.org/mozilla-central/rev/1b0455842788
https://hg.mozilla.org/mozilla-central/rev/777632b3319a
https://hg.mozilla.org/mozilla-central/rev/2f1e8f5b2fc2
https://hg.mozilla.org/mozilla-central/rev/7d270e96dfbf
https://hg.mozilla.org/mozilla-central/rev/1913c332695e
https://hg.mozilla.org/mozilla-central/rev/3ca24e761cc3
https://hg.mozilla.org/mozilla-central/rev/709078257c62
https://hg.mozilla.org/mozilla-central/rev/1b4a55820ddc
https://hg.mozilla.org/mozilla-central/rev/fae23bafbec1
https://hg.mozilla.org/mozilla-central/rev/260d6434bcc1
https://hg.mozilla.org/mozilla-central/rev/98e445343ef6
https://hg.mozilla.org/mozilla-central/rev/f7083b863a49
https://hg.mozilla.org/mozilla-central/rev/31963b9b2342
https://hg.mozilla.org/mozilla-central/rev/49323e9c1054
https://hg.mozilla.org/mozilla-central/rev/59fe7c6fccbb
https://hg.mozilla.org/mozilla-central/rev/1603092f907f
https://hg.mozilla.org/mozilla-central/rev/9ac44b431e3f
https://hg.mozilla.org/mozilla-central/rev/7330681cf4de
https://hg.mozilla.org/mozilla-central/rev/e44f2257d1ad
https://hg.mozilla.org/mozilla-central/rev/65c1552a1b96
https://hg.mozilla.org/mozilla-central/rev/8f0534e7ae1f
https://hg.mozilla.org/mozilla-central/rev/63c40227b2b7
https://hg.mozilla.org/mozilla-central/rev/9f0c707aea9d
https://hg.mozilla.org/mozilla-central/rev/c656c00c2557
https://hg.mozilla.org/mozilla-central/rev/0fee2352d648
https://hg.mozilla.org/mozilla-central/rev/6f602b70f67d
https://hg.mozilla.org/mozilla-central/rev/fc09f6fdeac6
https://hg.mozilla.org/mozilla-central/rev/51b83e2e559b
https://hg.mozilla.org/mozilla-central/rev/9901af844427
https://hg.mozilla.org/mozilla-central/rev/516172318999
https://hg.mozilla.org/mozilla-central/rev/d2f053ce1647
https://hg.mozilla.org/mozilla-central/rev/9314046d89eb
https://hg.mozilla.org/mozilla-central/rev/92c1a2fbc5dc
https://hg.mozilla.org/mozilla-central/rev/7a8b400a04f6
https://hg.mozilla.org/mozilla-central/rev/74d20d462889
https://hg.mozilla.org/mozilla-central/rev/0e22eb5eaa5c
https://hg.mozilla.org/mozilla-central/rev/83122b946cad
https://hg.mozilla.org/mozilla-central/rev/d5d11f9ac765
https://hg.mozilla.org/mozilla-central/rev/846009afb24c
https://hg.mozilla.org/mozilla-central/rev/449198942a70
https://hg.mozilla.org/mozilla-central/rev/32285ce7afc5
https://hg.mozilla.org/mozilla-central/rev/8800b67919eb
https://hg.mozilla.org/mozilla-central/rev/9a49327b1807
https://hg.mozilla.org/mozilla-central/rev/39f107c278d9
https://hg.mozilla.org/mozilla-central/rev/1a29be9439c1
https://hg.mozilla.org/mozilla-central/rev/bb6417a4cfac
https://hg.mozilla.org/mozilla-central/rev/351c0df7eb07
https://hg.mozilla.org/mozilla-central/rev/8ce505516255
https://hg.mozilla.org/mozilla-central/rev/539b69f0e211
https://hg.mozilla.org/mozilla-central/rev/0d38e43185fd
https://hg.mozilla.org/mozilla-central/rev/24809d566449
https://hg.mozilla.org/mozilla-central/rev/85b5cef7ef21
https://hg.mozilla.org/mozilla-central/rev/2c978604ead4
https://hg.mozilla.org/mozilla-central/rev/b0108b2cbf7d
https://hg.mozilla.org/mozilla-central/rev/335fb2fb164e
https://hg.mozilla.org/mozilla-central/rev/65ccb95df6d8
https://hg.mozilla.org/mozilla-central/rev/a62f6186e9d6
https://hg.mozilla.org/mozilla-central/rev/abd292499ec6
https://hg.mozilla.org/mozilla-central/rev/7798b0e4ad7c
https://hg.mozilla.org/mozilla-central/rev/0c303ca236a5
https://hg.mozilla.org/mozilla-central/rev/ad2c774d4e29
https://hg.mozilla.org/mozilla-central/rev/699496c38ca1
https://hg.mozilla.org/mozilla-central/rev/46a4e8215e95
https://hg.mozilla.org/mozilla-central/rev/b19cff76e239
https://hg.mozilla.org/mozilla-central/rev/ad0eef8ab89e
https://hg.mozilla.org/mozilla-central/rev/c91f12b557a1
https://hg.mozilla.org/mozilla-central/rev/54b2ab188fab
https://hg.mozilla.org/mozilla-central/rev/0c6ce519bbde
https://hg.mozilla.org/mozilla-central/rev/5454ff027576
https://hg.mozilla.org/mozilla-central/rev/2392ed5dd474
https://hg.mozilla.org/mozilla-central/rev/9f55c4ae34ed
https://hg.mozilla.org/mozilla-central/rev/ea458613d1d3
https://hg.mozilla.org/mozilla-central/rev/3cce5e6938f0
https://hg.mozilla.org/mozilla-central/rev/8ee615eeb0b1
https://hg.mozilla.org/mozilla-central/rev/12914026383c
https://hg.mozilla.org/mozilla-central/rev/169882535ace
https://hg.mozilla.org/mozilla-central/rev/9830ad4e1c46
https://hg.mozilla.org/mozilla-central/rev/7bd5e1f6940f
https://hg.mozilla.org/mozilla-central/rev/99b99cca6b7b
https://hg.mozilla.org/mozilla-central/rev/962120296b02
https://hg.mozilla.org/mozilla-central/rev/f96ea29c9818
https://hg.mozilla.org/mozilla-central/rev/5dbbbcfc51bf
https://hg.mozilla.org/mozilla-central/rev/557a4c793552
https://hg.mozilla.org/mozilla-central/rev/73900406dad6
https://hg.mozilla.org/mozilla-central/rev/dd3d80e100ce
https://hg.mozilla.org/mozilla-central/rev/3adad7191b94
https://hg.mozilla.org/mozilla-central/rev/807c62d3ae23
https://hg.mozilla.org/mozilla-central/rev/29adc25c262a
https://hg.mozilla.org/mozilla-central/rev/77156042480c
https://hg.mozilla.org/mozilla-central/rev/4e04c02f496f
https://hg.mozilla.org/mozilla-central/rev/4d528b84385b
https://hg.mozilla.org/mozilla-central/rev/40d0b3654462
https://hg.mozilla.org/mozilla-central/rev/02769edbf519
https://hg.mozilla.org/mozilla-central/rev/65562b1a98a3
https://hg.mozilla.org/mozilla-central/rev/e8c020c01186
https://hg.mozilla.org/mozilla-central/rev/5b666822bf0e
https://hg.mozilla.org/mozilla-central/rev/9b16bc2e5b33
https://hg.mozilla.org/mozilla-central/rev/1d686b81ccc5
https://hg.mozilla.org/mozilla-central/rev/e3db366464f6
https://hg.mozilla.org/mozilla-central/rev/78c304bf5e04
https://hg.mozilla.org/mozilla-central/rev/1cc47c2f746a
https://hg.mozilla.org/mozilla-central/rev/0131e96abfa0
https://hg.mozilla.org/mozilla-central/rev/5b625adf278a
https://hg.mozilla.org/mozilla-central/rev/3e18b3606a67
https://hg.mozilla.org/mozilla-central/rev/dc3478ddac7c
https://hg.mozilla.org/mozilla-central/rev/8b33eb369e9e
https://hg.mozilla.org/mozilla-central/rev/3ff262a1589b
https://hg.mozilla.org/mozilla-central/rev/15af040f73c4
https://hg.mozilla.org/mozilla-central/rev/8f74d06e3acc
https://hg.mozilla.org/mozilla-central/rev/6a477f69699e
https://hg.mozilla.org/mozilla-central/rev/31f19a260f00
https://hg.mozilla.org/mozilla-central/rev/2ca2be277ad7
https://hg.mozilla.org/mozilla-central/rev/7cb5b479d43f
https://hg.mozilla.org/mozilla-central/rev/dee11fb27e85
https://hg.mozilla.org/mozilla-central/rev/5ec008b3817d
https://hg.mozilla.org/mozilla-central/rev/fd6e040e5dfc
https://hg.mozilla.org/mozilla-central/rev/0c450f719f7f
https://hg.mozilla.org/mozilla-central/rev/9c0ddc852331
https://hg.mozilla.org/mozilla-central/rev/1ed708b01f44
https://hg.mozilla.org/mozilla-central/rev/ae53dadea1fb
https://hg.mozilla.org/mozilla-central/rev/2f6a58a81e26
https://hg.mozilla.org/mozilla-central/rev/e60e2f295fb7
https://hg.mozilla.org/mozilla-central/rev/a26d44969a83
https://hg.mozilla.org/mozilla-central/rev/9d3cd95e25db
https://hg.mozilla.org/mozilla-central/rev/a11786c39f82
https://hg.mozilla.org/mozilla-central/rev/d881b16dd8a6
https://hg.mozilla.org/mozilla-central/rev/9752aed37a4b
https://hg.mozilla.org/mozilla-central/rev/25a608864123
https://hg.mozilla.org/mozilla-central/rev/10bf2e8788d8
https://hg.mozilla.org/mozilla-central/rev/3d5503acf9a4
https://hg.mozilla.org/mozilla-central/rev/eda8a8c2fe63
https://hg.mozilla.org/mozilla-central/rev/7db62992db79
https://hg.mozilla.org/mozilla-central/rev/0391681090bb
https://hg.mozilla.org/mozilla-central/rev/818d30878859
https://hg.mozilla.org/mozilla-central/rev/1c42d3204891
https://hg.mozilla.org/mozilla-central/rev/58f47eacaf10
https://hg.mozilla.org/mozilla-central/rev/0627374afdb8
https://hg.mozilla.org/mozilla-central/rev/25b7005979d6
https://hg.mozilla.org/mozilla-central/rev/4803ed8a9de7
https://hg.mozilla.org/mozilla-central/rev/0b363fdb4b93
https://hg.mozilla.org/mozilla-central/rev/3e0f3414a635
https://hg.mozilla.org/mozilla-central/rev/0626e6c544e4
https://hg.mozilla.org/mozilla-central/rev/f81749164ac4
https://hg.mozilla.org/mozilla-central/rev/f531e8a780d5
https://hg.mozilla.org/mozilla-central/rev/d3e3d9a86baf
https://hg.mozilla.org/mozilla-central/rev/f547e3673690
https://hg.mozilla.org/mozilla-central/rev/c34ea4d71235
https://hg.mozilla.org/mozilla-central/rev/110b3ea88241
https://hg.mozilla.org/mozilla-central/rev/daa9eac709dc
https://hg.mozilla.org/mozilla-central/rev/d0b311007c03
https://hg.mozilla.org/mozilla-central/rev/c366748bd0bf
https://hg.mozilla.org/mozilla-central/rev/18d3bc91b71e
https://hg.mozilla.org/mozilla-central/rev/26913ec8db0b
https://hg.mozilla.org/mozilla-central/rev/a82ab80d7f91
https://hg.mozilla.org/mozilla-central/rev/936674a94c96
https://hg.mozilla.org/mozilla-central/rev/c385bb870413
https://hg.mozilla.org/mozilla-central/rev/edac9d01a9ac
https://hg.mozilla.org/mozilla-central/rev/bd14332f1185
https://hg.mozilla.org/mozilla-central/rev/9aa5aac4c287
https://hg.mozilla.org/mozilla-central/rev/f561883a24aa
https://hg.mozilla.org/mozilla-central/rev/5d9cfdf1deef
https://hg.mozilla.org/mozilla-central/rev/a4b7e102ef18
https://hg.mozilla.org/mozilla-central/rev/de8c14e4972f
https://hg.mozilla.org/mozilla-central/rev/1965757ee924
https://hg.mozilla.org/mozilla-central/rev/e0a2e54e4de8
https://hg.mozilla.org/mozilla-central/rev/8d80a4ba914c
https://hg.mozilla.org/mozilla-central/rev/400d8a0f1a7d
https://hg.mozilla.org/mozilla-central/rev/cca078b54e99
https://hg.mozilla.org/mozilla-central/rev/01569f2b1141
https://hg.mozilla.org/mozilla-central/rev/7057437ddf19
https://hg.mozilla.org/mozilla-central/rev/8c904d1fcdf3
https://hg.mozilla.org/mozilla-central/rev/844625c1d96d
https://hg.mozilla.org/mozilla-central/rev/1c3926cd7004
https://hg.mozilla.org/mozilla-central/rev/d621668762f4
https://hg.mozilla.org/mozilla-central/rev/af4c24767e48
https://hg.mozilla.org/mozilla-central/rev/c137938d4226
https://hg.mozilla.org/mozilla-central/rev/d1552c620c11
https://hg.mozilla.org/mozilla-central/rev/09db50c8f370
https://hg.mozilla.org/mozilla-central/rev/2a373d864092
https://hg.mozilla.org/mozilla-central/rev/786ea95e928b
https://hg.mozilla.org/mozilla-central/rev/bd3db9010131
https://hg.mozilla.org/mozilla-central/rev/0991ebfeb365
https://hg.mozilla.org/mozilla-central/rev/3bc5b0fab56a
https://hg.mozilla.org/mozilla-central/rev/d901db0726fe
https://hg.mozilla.org/mozilla-central/rev/310fdf39b051
https://hg.mozilla.org/mozilla-central/rev/ef817155231f
https://hg.mozilla.org/mozilla-central/rev/83f55605a59a
https://hg.mozilla.org/mozilla-central/rev/df9a58057245
https://hg.mozilla.org/mozilla-central/rev/ed2e505b5873
https://hg.mozilla.org/mozilla-central/rev/970ed33359b5
https://hg.mozilla.org/mozilla-central/rev/877a0fcc6da9
https://hg.mozilla.org/mozilla-central/rev/0552c0b4a079
https://hg.mozilla.org/mozilla-central/rev/370586931995
https://hg.mozilla.org/mozilla-central/rev/d3eb7bddf958
https://hg.mozilla.org/mozilla-central/rev/c186df8a088e
https://hg.mozilla.org/mozilla-central/rev/b2332c1d550e
https://hg.mozilla.org/mozilla-central/rev/0920243940ad
https://hg.mozilla.org/mozilla-central/rev/a802c8f458cb
https://hg.mozilla.org/mozilla-central/rev/336f58a54bd8
https://hg.mozilla.org/mozilla-central/rev/3fb02a012faa
https://hg.mozilla.org/mozilla-central/rev/a3925686efd4
https://hg.mozilla.org/mozilla-central/rev/c01614dfe8f6
https://hg.mozilla.org/mozilla-central/rev/542e982e7537
https://hg.mozilla.org/mozilla-central/rev/cc2d56c5c678
https://hg.mozilla.org/mozilla-central/rev/a64e03b3e760
https://hg.mozilla.org/mozilla-central/rev/519d7eb97e17
https://hg.mozilla.org/mozilla-central/rev/6b3195b0e545
https://hg.mozilla.org/mozilla-central/rev/7888e4be3d7e
https://hg.mozilla.org/mozilla-central/rev/718b57029512
https://hg.mozilla.org/mozilla-central/rev/0d2051d3d0eb
https://hg.mozilla.org/mozilla-central/rev/d948ec79fceb
https://hg.mozilla.org/mozilla-central/rev/7675ead797c8
https://hg.mozilla.org/mozilla-central/rev/9d8f6e354d8c
https://hg.mozilla.org/mozilla-central/rev/bde976e055f2
https://hg.mozilla.org/mozilla-central/rev/fa792634c1de
https://hg.mozilla.org/mozilla-central/rev/b53fd89c3789
https://hg.mozilla.org/mozilla-central/rev/d12c692c5671
Comment 366•3 years ago
|
||
Andreas, is there a blog post planned for this major update? I am guessing that we also need a mention in our Nightly release notes at least, correct? Thanks
Assignee | ||
Comment 367•3 years ago
|
||
I'll defer this to Nico, I happen to be assignee because I submitted the first patch :-)
Generally I agree though, those would both be great.
Reporter | ||
Comment 371•3 years ago
|
||
Bugs fixed and general improvements that have landed with the libwebrtc 2H2020 merge:
• Bug 1232234 - RTCP BYE is sent for every media stream on renegotiation, replaceTrack, or setParameters

• Bug 1730748 - WebRTC downgrades screen sharing resolution

• Bug 1690832 - Terrible video quality after negotiating video tracks 3 times

• Bug 1729110 - getSynchronizationSources() intermittently drops SSRC for video

• Significantly reduced main thread load
• Significant improvements in noise-suppression and auto-gain-control, slight improvements in echo-cancellation
Updated•3 years ago
|
Comment 374•3 years ago
|
||
Hi! Do I understand well, that this fixes Bug 1412333 (screen sharing -> 1 screen only in dual screen mode) or is it a pre requisite only?
Nice job!
Assignee | ||
Comment 375•3 years ago
|
||
I think it should be regarded as a prerequisite to future work on the linux screen capture backend.
Updated•3 years ago
|
Comment 377•3 years ago
|
||
Nico, could you clarify which of these release notes apply to this update?
https://github.com/webrtc/webrtc-org/blob/gh-pages/release-notes/index.md
Updated•3 years ago
|
Reporter | ||
Comment 378•3 years ago
|
||
Jonathan, we made our cut at dd9db8c23ac22a4d5ef6b4dc076c26af4258449c. This is within rel86, it does look like a number of things were back ported onto the rel86 since we made our cut, so I am not sure that all of the notes apply.
Comment 381•2 years ago
|
||
Copying crash signatures from duplicate bugs.
Updated•1 years ago
|
Updated•1 years ago
|
Updated•1 years ago
|
Updated•1 years ago
|
Updated•1 years ago
|
Updated•1 years ago
|
Description
•