Added the C++/Rust glue code for the rtcp-fb transport-cc type.
Extended the C++ unit test CheckRtcpFb
Extended the Rust unit tests for rtcp-fb.
MozReview-Commit-ID: 26hAexM0QeV
--HG--
extra : rebase_source : 1615700ac62ee5d61a26ad7234d42b82e4151109
Added support for whitespace in source-level attributes
Extended C++ unti test CheckSsrc
Extended Rust unti test for ssrc
MozReview-Commit-ID: 1xiYyZBYf5o
--HG--
extra : rebase_source : 26d8ee11592e40fa1c25021b86953c72b14636a7
This changes generate_sources_mozbuild.sh to call generate_sources_mozbuild.py
to generate sources.mozbuild and config files and removes the parts of the
script that are no longer necessary.
MozReview-Commit-ID: HgXIEw93z41
--HG--
extra : rebase_source : b54d23197e741c8e037ffc4b977c8d01c34197ef
This uses the cmakeparser to generate sources.mozbuild and the
config files for each platform.
MozReview-Commit-ID: CU6oIPJXtTw
--HG--
extra : rebase_source : b9f6707ed3f4ef6336a4fa2d75c46a5c26570528
Updated rsdparsa to 75d5c6df6728fbab502db06940062e0358536f9f from github
upstream
MozReview-Commit-ID: 9hr7DV6KTkK
--HG--
extra : rebase_source : c5b2c003e76489e267390402ebb5947cf3ec48b6
Added a bool field in RustSdpAttributeExtmap that tracks whether the direction was specified.
Added the correspodning C++/Rust glue code
MozReview-Commit-ID: yGL8yTDb49
--HG--
extra : rebase_source : d65f35051338673062d13b7bde591de880052558
Early bailout was preventing mDescription from getting set in MediaPipeline::SetTransport.
MozReview-Commit-ID: HIIva7R3fLe
--HG--
extra : rebase_source : 847b001372e6aedf59fc8f3f38b57a2a51b0f4e1
Summary:
I think the webrtc.org gtests are the only user of gflags in tree. We can switch
over to using gn to build this when we start building the tests using gn,
which is Bug 1430779.
Tags: #secure-revision
Bug #: 1371485
Differential Revision: https://phabricator.services.mozilla.com/D1802
--HG--
extra : rebase_source : ba496d6f262d3679031f0b933a80ce3e2a2236a5
Added the C++/Rust glue code for maxptime.
Added the C++ unit test CheckMaxPtime.
MozReview-Commit-ID: 58Qbrpktxwx
--HG--
extra : rebase_source : 1aed17367e230f0e397b196b759deaf18e4a3fd8
Changed parse_sdp to use StringView instad of raw pointers
Fixed all TODOs by using the existing StringView::into trait instead of doing a manual string conversion.
MozReview-Commit-ID: 5m7rLAu8vwS
--HG--
extra : rebase_source : f34cf389829772b4ca84d7ba895a8b71bd620f64
We were using an audio API not available prior 10.12. Also add a workaround for 3rd party audio cards with unusually high channels count.
This cherry-pick cubeb commits 59f5cb4ba01f21c4ad87e9404d1e470408e18505 and dbd61924736fbe1a1caf1cbd544f7d197f1836f7
Differential Revision: https://phabricator.services.mozilla.com/D2041
--HG--
extra : moz-landing-system : lando
Fixed the signature of the sdp_get_groups function in the C++/Rust glue code.
MozReview-Commit-ID: PljpUKk829
--HG--
extra : rebase_source : 92e221ce5e437bf5a994740f3b34f7336668e431
Nothing to do for this bug. All TODOs were solved by previous tickets.
MozReview-Commit-ID: JFvWvGRlJvy
--HG--
extra : rebase_source : e402f5844508f5b9809b9ad40184f88aba3574be
Added sanity check to check if the send rid in simulcast is defined by any send rid.
MozReview-Commit-ID: GISzaQqdqBI
--HG--
extra : rebase_source : 32416045cdb8c96dff72ee74d1d84121323d358f
Summary:
TaskQueue no longer requires an explicit call to BeginShutdown() as such we no longer have a need for AutoTaskQueue.
Depends on D1621
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1622
Removed all occurances of GetSsrcGroup in the C++/Rust and C++/sipcc glue code
Removed C++ unit test CheckSsrcGroupInSessionLevel
MozReview-Commit-ID: DImctiH6mUo
--HG--
extra : rebase_source : afd243f5658114f017d94d8bc9527b734901c303
Removed the code setting the channels for an rtpmap attribute in the C++ glue code.
Added Rust code that accounts the data in SdpMedia accordingly for rtpmap.
MozReview-Commit-ID: 2D5MVLJxXoh
--HG--
extra : rebase_source : ae54885e3d2cccdd04f5f758bddcf2d134f3a843
Added C++ unit test CheckAddDataChannel
Added C++ unit test CheckAddDataChannel_Draft05
MozReview-Commit-ID: HsSdFb0nKUe
--HG--
extra : rebase_source : 18fc6f3bdc04ea0983ce5376177a41df68b93ac2
Added sanity check that ensure that there is either a connection on the session level or in each media secion.
Extended create_dummy_sdp_session
Alterted Rust unit tests:
parse_minimal_sdp_with_emtpy_lines
parse_minimal_sdp
MozReview-Commit-ID: yVEhUvns57
--HG--
extra : rebase_source : ea354701995bf62c4231e654d12ad038a6e29bb0
The media/libpng/moz.build file overrides the C standard used via
-std=c89, per bug 1371266, which conflicts with the use of the
arm_neon.h header: compilation fails on the inline keyword, which didn't
exist in C89. We thus "bump" to the GNU89 standard, which is C89+GNU
extensions, including inline.
--HG--
extra : rebase_source : fe93a13e3bef8888e1874d2e94a6d8ef396aaf83
Unknown group semantics are no longer an error but a warning indicating that the lines was skipped.
Made rust unit test test_parse_attribute_group more explicit.
MozReview-Commit-ID: 7adMSzH195H
--HG--
extra : rebase_source : b5edcdd389d5435808cb4faed5b8bf816774d0e4
Added Rid attribute parsing
Added C++/Rust glue code for the rid attribute
Added SdpInternalError for ParseFloatError
Added Rust unit test for parse_rid in Rust
Added U16Vec in C++/Rust glue code.
The C++ glue code no longer parses rid attributes on his own if the rust parser is used.
Reworked Simulcast parsing in rust
Added C++/rust glue code for Simulcast
Enabled CheckSimulcast c++ unit test
Added sanity check, that checks for simulcast rids that have nt been defined
Enabled ParseInvalidSimulcastNoSuchRecvRid C++ unit test
Added comments with bug number to remove redundant parsing functions.
Removed C++ unit test ParseInvalidSimulcastNoSuchPt
Added C++ unit test ParseInvalidRidNoSuchPt
Added sanity check for rid pts.
MozReview-Commit-ID: 7rvsOKIbxVP
--HG--
extra : rebase_source : abfc74e5f57b51158cf9acdf81078e5a4147fb29
Implemented RsdparsaSdp::AddMediaSection
Added sdp_add_media_section to Rust/C++ glue code
Added SdpSession::add_media in Rust
Added C++ unit test CheckAddMediaSection
MozReview-Commit-ID: 8cUviY3atsb
--HG--
extra : rebase_source : 8efee17758cdfd4927f630c383ec281db5a6a9ef
This defers the call to register the refresh and move handlers to the
CaptureFrame() call so that they will be registered on the ScreenCapture
thread.
This also calls CFRunLoopInMode to process any pending sources in the
run loop corresponding to the ScreenCapture thread so that the
refresh and move notifications are received.
MozReview-Commit-ID: G4aEchnGuUz
--HG--
extra : rebase_source : b74d95015cccb2efa64a711a1824adb379531ca2
Added C++/Rust glue code
Added a u8 vector view in the C++/Rust glue code
Added fmtp attribute parsing in rust
Added the option to check for warnings that appeared in the rust parsing
Changed gtest CheckRedEmptyFmtp to check for errors in case of sipcc and check for warnings in case of rust
Extended rust fmtp testcases in rust
MozReview-Commit-ID: EXymPPKWVZk
--HG--
extra : rebase_source : a886880463c3b333c4743ef520eac4c76dc86d5b
Merged Rsdparser changes from github to mozilla central.
This includes: Syntax fixes for older rust versions
The TransportCC parameter for rtcp-fb
Serialization marcos and code
MozReview-Commit-ID: JqYttvTx2QS
--HG--
extra : rebase_source : 4f0c9e374fcdbd01d729cda2ddbfe5c67bf6cbc9
Added a sanity check, that checks for recvonly and whether simulcast defines send options
MozReview-Commit-ID: Hi5U9ZZVKY8
--HG--
extra : rebase_source : 67aa4d6cea6ad7d3956ce606c529e6023e9e5382
Moved RustSdpAttributeType and renamaed it to SdpAttributeType
Replaced the has_extmap_attribute functions by a generic has_attribute function
Added a sanity check, that checks for sendonly and if simulcast defines receive options
MozReview-Commit-ID: DXAEVu0SRap
--HG--
extra : rebase_source : c5732414f6e199c1e6a85d7d47921ca6ee601550
Same approach as the other bug, mostly replacing automatically by removing
'using mozilla::Forward;' and then:
s/mozilla::Forward/std::forward/
s/Forward</std::forward</
The only file that required manual fixup was TestTreeTraversal.cpp, which had
a class called TestNodeForward with template parameters :)
MozReview-Commit-ID: A88qFG5AccP
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Implemented Rust/C++ glue code for rtcp-fb
Implemented parsing support for rtcpfb-wildcard in rust
Activated c++ unit tests
MozReview-Commit-ID: 5xRSQz7pucZ
--HG--
extra : rebase_source : 97fdfda9134197381d16e0a61dda5357bba9e9da
This adds a FocusOnSelectedSource method to PCameras and uses it to focus the
selected window while window sharing. We can't just focus the window as soon as
it is shared because we have a live preview in the getUserMedia permissions
prompt which would cause the prompt to lose focus. Instead, this only focuses the
window when the sharing is not done from a chrome context.
MozReview-Commit-ID: 5jre75E3JLi
--HG--
extra : rebase_source : 5f5154fc9fc7590cc02eb25146e5bc20b2243fa3
This refreshes the gn-generated moz.builds with the change from previous
commit. Somehow, this does unrelated changes, there must be something
funky in the gn-moz.build-generator.
--HG--
extra : rebase_source : 7e1a9d75f7a80c0981b2534e4959ada6c611bae2
This adds a FocusOnSelectedSource method to PCameras and uses it to focus the
selected window while window sharing. We can't just focus the window as soon as
it is shared because we have a live preview in the getUserMedia permissions
prompt which would cause the prompt to lose focus. Instead, this only focuses the
window when the sharing is not done from a chrome context.
MozReview-Commit-ID: 5jre75E3JLi
--HG--
extra : rebase_source : 97f472f6ed1c5d6bed1af01fb7243a82b2629b03
We currently set the Android JavaVM pointer in MediaEngineWebRTC.
However, because of that, we end up setting the pointer in the child
process, even though we really want to set the pointer in the parent
process because that's where the camera will be accessed.
This patch makes us set JavaVM inside VideoEngine itself, where we
actually access the camera in the parent process.
MozReview-Commit-ID: 3TeLiiK2vyh
Update mp4parse-rust to 0c8e1d91464aaa63b82ebf076b63cda1df4230d1, which adds
uuid parsing support and exports the mp4parse_fallible feature from
mp4parse_capi.
Update gkrust to pass MOZ_MEMORY as a feature, and use that to conditionally
enable mp4parse_fallible/FallibleVec.
MozReview-Commit-ID: 2HDYbL2CGgJ
--HG--
extra : rebase_source : 6e8cf15241b0282406322cce29220a677edd1585
Update mp4parse-rust to 0c8e1d91464aaa63b82ebf076b63cda1df4230d1, which adds
uuid parsing support and exports the mp4parse_fallible feature from
mp4parse_capi.
Update gkrust to pass MOZ_MEMORY as a feature, and use that to conditionally
enable mp4parse_fallible/FallibleVec.
MozReview-Commit-ID: 2HDYbL2CGgJ
--HG--
extra : rebase_source : 299d9f8347d2f0ef0d66b9ea52a4ee7a31af0cd2
This removes the dispatch to the sts thread prior to calling
AudioConduit::InsertDTMFTone. There are assertions in ChannelProxy which
restrict the methods there to running on the main thread, so the current
code crashes immediately when inserting a tone in a debug build. The
inserted DTMF event ends up in a queue, so there is no reason not to just do
the insertion from the main thread.
MozReview-Commit-ID: G8JM9QDLrGF
--HG--
extra : rebase_source : 65168ee08efa5fc1960e35fd5acf4bdde0420b84
This allows removing locking, and allows other threads to progress without
taking the lock, hence lowering the probability that the lock will be taken for
a long time when we need to pull NeqEQ.
MozReview-Commit-ID: HMO67A0hher
--HG--
extra : rebase_source : aa5c77895eb57d60b61d9a8a5822e53593348830
We made NotifyPull parallel to try to lower the load, and we initially measured
an improvement. However, we did the measurements with a profiler that did an
aggregation of the results. Our results had an high variance, so the mean load
was in fact not meaningful.
More careful measurement performed without doing any aggregation show that,
under load, relying on the fact that the scheduler schedules the tasks on time
is too risky, and that the code is fast enough to not have to parallelize.
MozReview-Commit-ID: CMhSn8Sc0OO
--HG--
extra : rebase_source : cfb41f861089bce9e10446bee81c13f8565ba90e
This also causes a lot of dropouts. We don't need to lock here. NetEQ is thread
safe, and its created in the ctor. The rest of the members are made atomic or is
simply never accessed in multiple threads.
MozReview-Commit-ID: 2fRw5ZgxdpQ
--HG--
extra : rebase_source : f2aa082a3e856e873cfcd96ff721ccdc77df3633
This accounts for half of our audio dropouts, there is very high contention on
this piece of data.
MozReview-Commit-ID: 2HSfqZHT2MK
--HG--
extra : rebase_source : 10c451ac60563a0f1c14a314f5a12cc45055e20b
This pulls in the fixes to shutdown RPC channels correctly when all
client proxies are dropped. This stops leaking fd and shmem.
MozReview-Commit-ID: 8Kb0iFPn8Pc
--HG--
extra : rebase_source : 8fcce9dfbec570f4d3ec035a6dd6576d1d137cd5
This hard codes the visual studio version to 2015. We did the same thing for the
gyp build. It also sets default paths for visual studio, which are ignored by the
remainder of the build system.
This was required to get gn code generation working on a fresh install of
Windows. I must have had similar changes on my old Windows VM but missed
commiting them as part of the gyp to gn build switch.
MozReview-Commit-ID: 7fYngpdIwxh
--HG--
extra : rebase_source : de24b50f8e19465d8c145ce96c31d4ad7cc52e57
This patch converts all the prefs in MediaPrefs to the new StaticPrefs system.
Note that the "media.wmf.skip-blacklist" pref was present in both MediaPrefs
and gfxPrefs. The copy in MediaPrefs was never used; this explains why this
patch does not add an entry for it to StaticPrefList.h.
Note also that the patch removes themedia.rust.mp4parser pref, because it's
unused.
MozReview-Commit-ID: IfHP37NbIjY
--HG--
extra : rebase_source : df84ea813b7c366d7be663c696891325610149c8
A minimized window has a resolution of 1x1. Although we removed minimized windows from the list
of available windows to share, nothing prevents the user from minimizing it during a call. With
the current code, this will cause InitEncode to fail, resulting in a fatal release assert.
I tested this patch with window sharing on meet.google.com and I was able to minimize and restore
the window several times without problem. While minimized, the window appears as a black screen
to the other meeting participants. It renders normally when restored.
MozReview-Commit-ID: LE2NBiEy8nw
--HG--
extra : rebase_source : f95fd3f797e9f7262a938087ce3fb1e27f743920
It is written under lock on the controlling thread (CamerasParent) in
StartCapture/StopCapture.
MozReview-Commit-ID: E7eq1YElhwt
--HG--
extra : rebase_source : f37b666d84c6710ac0d5c56002b82c707635f49b
If we stay in the critical section, and the StartCapture() is a reconfiguring
one, we risk deadlocking with IncomingFrame which runs on the camera thread.
MozReview-Commit-ID: 5rU4urrBWxr
--HG--
extra : rebase_source : 4c6e0c1e02eb1116a1fe433681bf4ad36f47186a
Looper lifetime must be handled by external callers as otherwise internal
callers may accidentally and unknowingly quit the looper and essentially
terminate the camera thread, stopping any flow of frames and preventing future
messages.
In this case, a reconfig of the capture settings through startCapture() causes
startCaptureOnCameraThread() to restart the capture by calling into
stopCaptureOnCameraThread() (quitting the looper) and then re-calling
startCaptureOnCameraThread() (not restarting the looper as that is invalid).
The camera thread is set up by startCapture() on the external calling thread,
which will never know that a seemingly graceful camera thread operation stopped
the camera thread altogether, and so it cannot take any action.
MozReview-Commit-ID: DUTFdanTan1
--HG--
extra : rebase_source : afeb80aa8b2596a2615f57ec4af182a837323b7e
This limits screensharing simulcast to a single layer. When window sharing, our
source video can have arbitrary dimensions. If one of those dimensions ends up
being odd, the aspect ratio of the smaller layer will not match the aspect ratio
of the odd sized layer, causing a runtime assertion failure and crash.
It is not sufficient to prevent the creation of odd sized layers in
CreateEncoderStreams because the user can resize the window while it is being
shared, which will cause a fatal assertion prior to the streams being recreated.
When switching back from window sharing to camera, a call to
CreateEncoderStreams will occur with resolutions matching the dimensions of
the window that was just shared. To prevent a crash, this also adds a check
which prevents the creation of layers with odd resolutions.
Looking at cricket::GetSimulcastConfig for the version of webrtc.org in tree,
the number of simulcast layers is limited to one, or two if a field experiment
is enabled. That code also limits resolutions at which screensharing is allowed
as well as the number of layers that can be created for each resolution, and
ensures that each layer is exactly half the size of the layer above.
Adding these new constraints to CreateEncoderStreams makes us more consistent
with what the webrtc.org code would do when creating streams, which should
help to avoid more assertion failures in the future. Long term, I believe we
should just switch to using cricket::GetSimulcastConfig.
MozReview-Commit-ID: 8gjdY5GPPjl
--HG--
extra : rebase_source : b13b7acdac7f1e0b6016417b83bbe97dc2417a92
This limits screensharing simulcast to a single layer. When window sharing, our
source video can have arbitrary dimensions. If one of those dimensions ends up
being odd, the aspect ratio of the smaller layer will not match the aspect ratio
of the odd sized layer, causing a runtime assertion failure and crash.
It is not sufficient to prevent the creation of odd sized layers in
CreateEncoderStreams because the user can resize the window while it is being
shared, which will cause a fatal assertion prior to the streams being recreated.
When switching back from window sharing to camera, a call to
CreateEncoderStreams will occur with resolutions matching the dimensions of
the window that was just shared. To prevent a crash, this also adds a check
which prevents the creation of layers with odd resolutions.
Looking at cricket::GetSimulcastConfig for the version of webrtc.org in tree,
the number of simulcast layers is limited to one, or two if a field experiment
is enabled. That code also limits resolutions at which screensharing is allowed
as well as the number of layers that can be created for each resolution, and
ensures that each layer is exactly half the size of the layer above.
Adding these new constraints to CreateEncoderStreams makes us more consistent
with what the webrtc.org code would do when creating streams, which should
help to avoid more assertion failures in the future. Long term, I believe we
should just switch to using cricket::GetSimulcastConfig.
MozReview-Commit-ID: 8gjdY5GPPjl
--HG--
extra : rebase_source : 5a22f6d0a995303e6a4039eafc056631fbb86415
The cameraThread is set by startCapture(), so a failed startCapture() that
quits the Looper and runs the cameraThread to completion needs to set
cameraThread back to null for consistency.
Likewise, stopCapture() shall always quit the Looper and set cameraThread to
null.
MozReview-Commit-ID: H1ExLyTixYw
--HG--
extra : rebase_source : 472b657cd8219533a5878f5b268b6288e1fe6320
Pull in fix for cubeb channel layout to PulseAudio channel layout.
MozReview-Commit-ID: L9v3cYM5PAY
--HG--
extra : rebase_source : bc4358efcd6ca6276c242ad3beec7f71288f36d7
