Call the device binding code in gtests, and have a test GMP which returns the
device ID it was passed in a message, so that we can verify that the id the GMP
was passed is the same as the id generated in the parent.
MozReview-Commit-ID: Gjqvo6dRK1D
--HG--
extra : rebase_source : bea5acc878a639fb819051e19e23533c14c19927
I want the EME device binding/nodeId code to be callable from gtests, as well
as in plugin-container. I need this because I want to add a gtest that ensures
that we don't regress the EME/GMP device binding code. I want to call the GMP
device binding code in the gtest and in the GMP process, and compare the
result.
So we need to make it possible to link the device binding code into the gtests
as well as plugin-container. So move all code that device binding calls into
librlz, to make it easier to link against all the code required.
Note: the device binding code needs to be statically linked into
plugin-container so that it's covered by the Adobe CDM's voucher tool.
MozReview-Commit-ID: AvBAe1dh49Z
--HG--
rename : ipc/app/sha256.c => dom/media/gmp/rlz/sha256.c
rename : ipc/app/sha256.h => dom/media/gmp/rlz/sha256.h
extra : rebase_source : f60f1e68649fa90cbe1f2fe09f5f69948444b1df
I want the EME device binding/nodeId code to be callable from gtests, as well
as from in plugin-container.
First step is to move the device binding code into a discrete file, so I can
also link that into gtests, and call it from there to compare the result with
what's in the GMP process.
MozReview-Commit-ID: 9xT2rp3hWW
--HG--
extra : rebase_source : 824c7a9841bce83c438decad48ce210f6c2a5571
getLocalStreams and getRemoteStreams have been removed from the spec.
Also, getLocalStreams becomes a problem now that addTrack takes any MediaStream
as the container for the added track.
The addTrack()'ed MediaStream (perhaps not containing the track sent over the
pc - perhaps containing other tracks not sent over the pc!) will be returned
from getLocalStreams.
MozReview-Commit-ID: JUVCUM32mPR
--HG--
extra : rebase_source : 22373da7e02b315f0f4252c1986e55e960694a69
extra : histedit_source : a10d62b9c1d954090ad8c1444759d0e51a580c31
It is now valid, with its own test.
MozReview-Commit-ID: CLdCuRdwYE4
--HG--
extra : rebase_source : f5420b2b9eaaa1ebe04d787db6b0aec1e157a792
extra : histedit_source : 1490988ff154b37d51256abf0ae2e61bcb148461
This tested that we were throwing on adding a track with a constructed
MediaStream, which we now allow.
MozReview-Commit-ID: 37QfxZngvqI
--HG--
extra : rebase_source : 3fec846b200def54edbef6bc429eff1eb75e7973
extra : histedit_source : 819a5782fdb814f7e401972999579f406ca59234
This change RTCPeerConnection.addTrack() to allow any MediaStream as argument.
The MediaStream is in the end used as an identifier of how the tracks will be
grouped together on the receiving side of the peer connection.
MozReview-Commit-ID: 9wDPOmMHYDc
--HG--
extra : rebase_source : 5fd59853c2d207cbcdaa1e4a767b3c4de20a1beb
extra : histedit_source : 2b88e899a329df07a46c1f12e449956d59645cf7
We have GetTrackById() now that does essentially the same thing.
Also, GetVideoTrackByTrackId() was too focused on the owning MediaStream and
didn't work.
MozReview-Commit-ID: 9z3rg4FI9H8
--HG--
extra : rebase_source : 7e295dc19b41b62f809977b6b73d2729f127d08a
extra : histedit_source : 39ab0f08939825c341b136150760e02c92fac970
