In order to raise an assertion in CanIgnoreIfNotVisible() which will be
introduced in part 3 when the cumulative hint is not properly, we should skip
the calculation when mProperties is empty.
BuildSegmentsFromValueEntries now needs base nsStyleContext to calculate
the change hints.
If the change hint is not set correctly, we will check it in
CanIgnoreIfNotVisible() introduced in a subsequent patch (part 3).
This currently can't happen as no MediaDataDecoder ever return a null sample.
MozReview-Commit-ID: BucIadubght
--HG--
extra : rebase_source : 4c6f3dc1d5581bdb9d58ba3b7cc1659c57f40d8e
If we're in waiting for data mode, the decoder must have already been drained and we want the waiting promise to be resolved upon the next run of UpdateReceivedNewData.
MozReview-Commit-ID: Hf8pFFyQmjJ
--HG--
extra : rebase_source : c51ed65c7d7c4a9ee877e6f9420f6534480e7cb5
Amendment to bug 1244410. If no frames had been output yet, last dts would have been INT64_MIN.
MozReview-Commit-ID: LOdWLpyuLYm
--HG--
extra : rebase_source : f842d2214b1e82f3b069e843157b95d87e62fa01
A bit of a shot in the dark, but it is possible that data got received but that information got lost as reset was called.
MozReview-Commit-ID: 1KjQeCFsGPJ
--HG--
extra : rebase_source : 3a522045bde0658fdfeccbf4d0cac11b43bc35d7
The condition will be perfectly handled by the MediaFormatReader anyway.
MozReview-Commit-ID: Dm6evq6T4t6
--HG--
extra : rebase_source : 6e49cfae68bfa856aad891faf3cea565b152e565
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