Two things here:
- The default stack size of the thread pool is not very big, it's better to
stick the buffer we need on the object.
- There was a unit mismatch between bytes and samples. This changes the name to
make the unit more obvious, and fixes its usage by dividing by the sample size.
MozReview-Commit-ID: 19bbS6iGvTw
--HG--
extra : rebase_source : bb5c2c074b8c1c3d69e002c8d82f4f72cc57582d
Instead of asking for permission in VideoCaptureDeviceInfoAndroid.java,
we now merely check for permission there. The actual permission prompt
now happens in WebrtcUI.js, using the new
"getUserMedia:ask-device-permission" and
"getUserMedia:got-device-permission" notifications.
MozReview-Commit-ID: DSVPjjW2JNR
Currently, if permission is first denied, the list of cameras is empty.
However, if permission is later granted, the list stays empty because we
never try to refresh the list. This patch causes us to refresh the list
when necessary.
MozReview-Commit-ID: 5eodPCWVyaP
Still left TODO:
* add an aboutWebrtc.js section
* write tests
MozReview-Commit-ID: DwFxq19KWeu
--HG--
extra : rebase_source : fad3018d851316af83df48c62db16028a1a84b5c
ViERenderer is not used anywhere but has a couple calls to the obsolete
GeckoAppShell orientation listener. The entire ViERenderer.java file is
getting removed in the upcoming WebRTC update, so we should just go
ahead and remove those lines.
MozReview-Commit-ID: AwG7dBg5MV8
- Avoid any potential for this going away from underneath the dispatch
to STS thread.
- Added notes in PeerConnectionImpl on the test-only nature of the
AddRIDExtension, AddRIDFilter, and GetMediaPipelineForTrack methods.
PeerConnectionImpl::GetMediaPipelineForTrack by returning a reference
to the RefPtr instead of a copy.
MozReview-Commit-ID: EwMr9ulKtm8
--HG--
extra : rebase_source : 55c8b14f63020feda57accd2b4b331de708866c4
Now that Chrome release is bundle-aware, let's reapply the patch to
properly emit port 0 for m-lines in sections with the bundle-only
attribute.
MozReview-Commit-ID: 8RftSXIzIpD
--HG--
extra : rebase_source : 6f9c4cb6b322aec7c00060827e1f5e7852f8acfc
This function is arguably nicer than calling NS_ProcessNextEvent
manually, is slightly more efficient, and will enable better auditing
for NS_ProcessNextEvent when we do Quantum DOM scheduling changes.
Now that RID filtering (Bug 1358224) has fixed the intermittant oranges
from Bug 1351531 and 1351590, remove the functionality from MediaPipeline.
MozReview-Commit-ID: 1rED3iaHRCK
--HG--
extra : rebase_source : 5539f9badc99a8abfcf5419b436718233e9ab567
Turns out since Firefox doesn't receive simulcast streams, we never
noticed this leak. Convert RTPHeaderExtension.rid from a char* to
rtc::scoped_ptr<char[]> so it gets deleted properly. This also
requires a new copy constructor and assignment operator.
MozReview-Commit-ID: Jh4Gp4dAl9g
--HG--
extra : rebase_source : 8c1081fecd6e56a8f932af54fbd294adb85866f5
The simulcast mochitests setup the receiving PeerConnection to receive
simulcast video streams which Firefox doesn't really support. Without
a test media server, this is about the best we can do and still test
simulcast.
Unfortunately the two simulcast streams arriving with different ssrcs
(as expect) exercises code we have to deal with some services switching
ssrcs midstream. In the tests, this causes intermittent failures
because the test is waiting to receive a certain ssrc, and the receiving
VideoConduit has switched to the other ssrc.
This change adds the ability to filter on RID at the MediaPipeline level,
which we can setup prior to media flowing. This avoids the ssrc switching
issue since the VideoConduit only receives one ssrc until we change the
RID filter to the second RID. At that point, the VideoConduit sees a new
ssrc and the switching code works as intended.
The modified mochitests setup the RTP stream id header extension, and then
filter on each of the RTP stream ids in turn.
MozReview-Commit-ID: KApfaxMX8rl
--HG--
extra : rebase_source : d7ae88d9675acd7b3700f342ca6a68d0bbb0ced5
The simulcast mochitests exhibit an intermittent failure due to ssrc-based
filtering that can be solved by filtering by RID. The RTP header parser
used in MediaPipeline also needs to have the RID RTP header extension
specified in order for it to properly parse the RTP header and allow
filtering on RID.
MozReview-Commit-ID: E54HCGLVYDk
--HG--
extra : rebase_source : b53085f23cb6558611aa7622f55637e19439c9c3
Its content is a no-op since bug 1322707.
The code in the same directory, though, is meant to move to gtests
(bug 1316611).
--HG--
extra : rebase_source : fa269a034fd327856fde8d0673de58eba9b02d8e
The webrtc gyp files have a 'build_for_tool' flag that controls among other
things what defines are provided at build time. This meant that during a
firefox valgrind build webrtc would still specify NVALGRIND, thus disabling
some valgrind macros. Similarly there are flags for asan and tsan that we
should probably have been specifying as well. This patch sets the
'build_for_tool' flag to the appropriate value when building under valgrind,
asan, and tsan.
Paul Ellenbogen
Nils Ohlmeier [:drno]
Paul Adenot
Masatoshi Kimura
Wes Kocher
Randell Jesup
Jim Chen
Nico Grunbaum
Michael Froman
Nathan Froyd
Munro Mengjue Chiang
Andrea Marchesini
Florian Queze
Mike Hommey
John Lin
Vineet
Eric Rahm
James Willcox