Upgrade WebRTC.org code to stable branch 3.34

RESOLVED FIXED in mozilla26

Status

()

Core
WebRTC
RESOLVED FIXED
5 years ago
a year ago

People

(Reporter: jesup, Assigned: jesup)

Tracking

(Blocks: 1 bug)

22 Branch
mozilla26
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [webrtc][getusermedia])

Attachments

(1 attachment)

(Assignee)

Description

5 years ago
Niklas Enbom indicated to me that Chrome 29 is using the 3.34 branch of webrtc.org, so we should update to that as well.

Target is to land early in 26
(Assignee)

Comment 1

5 years ago
Created attachment 795268 [details] [diff] [review]
Rollup merge of all changes to media/webrtc/trunk

To be applied on top of an import patch that replaces media/webrtc/trunk entirely with a copy of 3.34.

Note: doesn't include the added Windows video input file (BasePin.*, etc) we added; we'll avoid removing them in the base update.

Green on all platforms in Try.  Tested locally on Windows, Linux and B2G (Peak)

Comment 2

5 years ago
Let's see if we can get some testing on Mac before this lands.
(Assignee)

Comment 3

5 years ago
>Let's see if we can get some testing on Mac before this lands.

Was planning on it, and Android as well, and I've been reviewing all the changes.  I've now tested Mac and it's quite happy (after I upgraded to clang 4.2... - nothing to do with this code).

It's quite likely something in the BSD ports will break with this update, but I won't block on that pre-landing.  I can help with providing the (large) base import patch directly to someone who wants to try it ahead of landing, however.  I believe I've properly merged over all the BSD patches currently in the tree as of when I took the rollup; I'll do an hg diff to try to extract any changes since the initial 3.34 rollup creation before landing.
I can give this a go on OpenBSD at least..
Fwiw, what you sent me privately builds fine on OpenBSD, with https://bugzilla.mozilla.org/attachment.cgi?id=757662 on top to enable webrtc on *bsd. As for runtime testing, i didnt do some since a while, but i should get back to it.

So f+ for me :)

Comment 7

4 years ago
https://hg.mozilla.org/mozilla-central/rev/c118114b08f1
https://hg.mozilla.org/mozilla-central/rev/df48be62a887
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
(Assignee)

Comment 8

4 years ago
(Copying from some email for reference)

After reviewing *all* the differences between 3.30 and the patched 3.34 I have ready, these are the major differences:

5 zillion Include path changes
Generic config setup for passing down to other parts (video, etc)
more use of sinc resampler
*major* screen sharing update (perhaps to support Chromecast better)
transmission-time header extension
Support for a "padding" bitrate (below that rate it will pad what it sends, I guess to "reserve" the bandwidth)
Paced sender changes
Bitrate estimator changes (extensions, algorithm rework/code-style-cleanup, etc)
   Note: Code style changes and cleanup make it hard to evaluate the differences without some real time
Removed support for VideoCaptureImpl::DeliverEncodedCapturedFrame() (it assert()'s now)
   Note: This was the code that allowed encoders-in-the-camera; they removed support for this in a number of places
vp8: drop encoder config to 2 cores (from 4) for larger-than-640x480, and from 2 to 1 core for (>320x240 && <=640x480)
vp8: encoder reset logic changes
video jitter buffer rework to separate out decodable frames from incomplete
Improved "NACK isn't working" error recovery for video
Typing detection on OS's other than windows (not sure how complete it is)
compare_videos tool
some minor a/v sync changes
NetEQ exposes/adds-controls-for a bit more more audio delay management
tons of test changes I didn't review much (largely to support the above changes)
(Assignee)

Updated

4 years ago
Blocks: 932112
Blocks: 818631
You need to log in before you can comment on or make changes to this bug.