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
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)
Let's see if we can get some testing on Mac before this lands.
>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 :)
Tested locally on Windows, Mac, Linux (Fedora 17), Android (Nexus 10 and Galaxy S4), B2G (Peak) Try (all but android): https://tbpl.mozilla.org/?tree=Try&rev=679dd96fec64 Try (android): https://tbpl.mozilla.org/?tree=Try&rev=9a0cdd05831f https://hg.mozilla.org/integration/mozilla-inbound/rev/c118114b08f1 https://hg.mozilla.org/integration/mozilla-inbound/rev/df48be62a887
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
(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)
You need to log in before you can comment on or make changes to this bug.