We would only abort early if new data had been received. Which may not always be the case.
MozReview-Commit-ID: HvAUq5CTc7F
--HG--
extra : rebase_source : a24b6c8bf2a31b0c9e69fc748ebb9b80b5c0d286
This is how it was meant to work when the refactor landed in Bug 1208371.
We have no test coverage of seeking apparently.
MozReview-Commit-ID: IhyGbjctO7E
--HG--
extra : rebase_source : 70f1ab777d8f7d6632d24f7134415ad13f73d166
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
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
