This does two things:
- Stop calling the callback when initializing cubeb prefs callback, see the
comment block for the rationale.
- Change the pref name so that the problem does not continue to be triggered
with users that have the old pref name in their profile.
MozReview-Commit-ID: 9Ty7Mt9WZpP
--HG--
extra : rebase_source : 1ed504be98c279f54a1a6c4168709b3ba78103e5
They are no longer supported and can't work with API >= 16
MozReview-Commit-ID: JkftKxW5OtY
--HG--
extra : rebase_source : 6ed4032141add293d21354640c96fc75adc565d9
Bug 1326294 is fixed and we don't need the debug code anymore.
This help reduce the coupling with HTMLMediaElement and make MediaDecoder
easier to be reused by Servo.
MozReview-Commit-ID: KCwAjoQFPkS
--HG--
extra : rebase_source : 0c98899f63edb5971ddecb812635c9a6f693d448
Only suspend decoding when the pref is on, but resuming could be done when the
pref is off.
MozReview-Commit-ID: JDh1pRXNhc8
--HG--
extra : rebase_source : 1a075c9eff5abe0eae7bd929d9c632d5b49a63be
Updates to Chromium revision 6e4c388c0117fe408b66fbede91081fb1018c5fe.
Adds Verified Media Pipeline function definitions.
MozReview-Commit-ID: 2H8mMNacQqR
--HG--
extra : rebase_source : dc91151c5ffe94f59346b9f4cbab587e6c0701a3
Update to chromium revision 6e4c388c0117fe408b66fbede91081fb1018c5fe.
Includes cdm::ContentDecryptionModule_9 and cdm::Host_9 definitions,
HDCP definitions, and 10 and 12 bit image format definitions.
MozReview-Commit-ID: bYH3OBSzuT
--HG--
extra : rebase_source : d062d233c9a2b59aa5ae5c6e0584ed13b7c83e6e
Note we will move OnDecodeWarning() from MDR to MFR when removing MDR.
MozReview-Commit-ID: 92jpwy6ghH2
--HG--
extra : rebase_source : 72e84f364cdab589efe60e70a071816cb4404955
extra : intermediate-source : fc7ff704e2096935b949ed8b9f6e73945db56a79
extra : source : 6e65a382de5de478948d434fc238a6afe231d2ac
Note we put OnWaitingForKey() in MediaDecoderReader for MediaDecoder references
MDR instead of MFR. The function will be moved into MFR when we remove MDR and
have MediaDecoder reference MFR instead.
MozReview-Commit-ID: LBGfGmc6yFm
--HG--
extra : rebase_source : 473c95cf6eb5e7e4065f9c1251af7dacb78538a5
extra : intermediate-source : 85981e2bafa1047f8321c02de6f0726c32506811
extra : source : 5203bf6895273701ef36a81d2e827e7a7c219fdb
We will use MediaEventSource to plumb the event from MFR to the media element.
MozReview-Commit-ID: 4gaEx7vYybE
--HG--
extra : rebase_source : fd595399e2db4e76ad117636768e160c2f054775
extra : intermediate-source : 1fc86c40dc83e79306c721b1acb0f31803181509
extra : source : d24b62a6041966b2639e5543c9ecccc4f7656a0d
1. Pause the Exoplayer when navigating to another page and resume playback when navigating back.
2. Fix the OOM issue.
MozReview-Commit-ID: 5UGmBzpObsb
--HG--
extra : rebase_source : f8f268612687669e1b31881465600b02b3531c55
We will use MediaEventSource to dispatch the 'encrypted' events.
MozReview-Commit-ID: KY3nS9OrysI
--HG--
extra : rebase_source : 4e1fa125b099567426f5a6ea2c825b77d407b2c4
extra : source : 8413b0625159d85a5814cb3bd748121653735e96
So we can reduce dependency on AbstractMediaDecoder.
See bug 1378295 comment 1 for the detail.
Note it is not ideal to repeat |init.mCrashHelper = ...| several times in
this patch. We will re-visit it to reduce code duplication after bug 1378295
is done.
MozReview-Commit-ID: AEC56ukqtYr
--HG--
extra : rebase_source : 07554566af74b65f391811e55847e58365ac81fe
extra : source : 7f613117f815369f65256408b221131683c0dd82
1. Moving UpdateA/VInfo to HLSTrackDemuxer and related changes.
2. Handle audio format change by changing the stream id.
MozReview-Commit-ID: IJmSvygZLVf
--HG--
extra : rebase_source : fb90c1454f20ff930626b6febf74b7cb0c4d20b9
This patch is going to loose the criteria of skip-to-next-key-frame.
The original rules are here:
http://searchfox.org/mozilla-central/rev/31311070d9860b24fe4a7a36976c14b328c16208/dom/media/MediaFormatReader.cpp#1559
Skip-to-next-key-frame is triggered if the playback position is LARGER than the next key frame time.
But, from the video-track point of view, when the skip-to-next-key-frame is triggered, it skips to the next-next key frame.
Here is an example, say, we are playing a media file with its playback position at time _a_,
and its video decoding is falling behind at time _v_.
The next key frame is at time _k1_ and next-next key frame is at time _k2_.
a
----|---------|---------|-------------|----------------> time
v k1 k2
When the playback position _a_ passes _k1_ (_a_ > _k1_), the skip-to-next-key-frame is triggered,
and the demuxer jumps to _k2_ directly.
The idea here is to give a chance when (_a_ == _k1_), let demuxer jump to _k1_ and see if the video decoding could catch up.
MozReview-Commit-ID: 6aRSYDOI1ds
--HG--
extra : rebase_source : c448df7af9f83b9127bad9bae28f353b40669b7f
So we can remove AbstractMediaDecoder::CanonicalDurationOrNull() later.
MozReview-Commit-ID: 6zJCFDsCZPC
--HG--
extra : rebase_source : 66af1674651667a2ab9e82b85e5c730f8eb5c227
extra : intermediate-source : 6c5eccd5fc68bf663e1ffa9d5b57c5a2a2721b14
extra : source : 4b30670e2d75260b21fa953f9c7219e3e485c396
It would be handy we want to pass more data to the constructor.
MozReview-Commit-ID: 3AUUsTbv534
--HG--
extra : rebase_source : 8d230c85addf1ba296e6a0512f0d18ebd41c0d17
extra : source : e6568e9fa24f52c59baecaa16aa044b492f407fb
Retrieve pref from MediaPrefs, which is more efficient than
Preferences::GetInt().
Also refactored computations to avoid unnecessary type conversions.
MozReview-Commit-ID: Ii27lthRRNI
--HG--
extra : rebase_source : d1ea46060cd2c35b7fd07a191184c0318187c080
MP4TrackDemuxer::GetNextSamples set mExtraData and it should be valid. This sample will later be rejected by the H264Converter.
The case would also fail if the video codec was VP9.
MozReview-Commit-ID: 5nXoRFJ6ntx
--HG--
extra : rebase_source : 76bfac15373fdccb3f2286bd3cd0999236509e1e
So we are able to dispatch NotifyDataArrived() to MediaDecoderReader in P2.
MozReview-Commit-ID: 3RM66uTvYSc
--HG--
extra : rebase_source : 40311cf27fefbd2046016fb246a3a4ccfce845a8
extra : source : 515d9b3b3cd4b0b30d2fd8196b48c55e14466263
Note MediaDecoderReader::GetBuffered() accesses mResource which is null
when it is actually a MediaFormatReader. However, it is OK for MediaFormatReader
will override UpdateBuffered() and will never call GetBuffered().
MozReview-Commit-ID: 5qcH4PHDzin
--HG--
extra : rebase_source : acb3ef2d981509a397045110cbb7cbecba8d5bee
extra : source : 5f66ecf33bfaecceaab8d9020175e26c5ca5cd1b
Most of this patch is updating a few places that use gfxMatrix to use
the equivalent-but-differently-named functions on MatrixDouble:
- Translate/Rotate/Scale get turned into PreTranslate/PreRotate/PreScale
- Transform(Point) gets turned into TransformPoint(Point)
- gfxMatrix::TransformBounds(gfxRect) gets turned into
gfxRect::TransformBoundsBy(gfxMatrix).
- gfxMatrix::Transform(gfxRect) gets turned into
gfxRect::TransformBy(gfxMatrix).
The last two functions are added in this patch as convenience wrappers
to gfxRect instead of Matrix.h because we don't want Matrix.h to "know"
about gfxRect (to avoid adding gecko dependencies on Moz2D). Once we
turn gfxRect into a typedef for RectDouble these will be eliminated
anyway.
MozReview-Commit-ID: BnOjHzmOSKn
--HG--
extra : rebase_source : cf1692d1f0d44a4b05d684a66678739181a426d5
This involved a change to BackgroundHangMonitor, as it initialized sDisabled
incorrectly to false, instead of true, We need sDisabled initialized to true, as
we cannot assume that it is enabled until BackgroundHangMonitor::Startup() is
called.
MozReview-Commit-ID: 94slLTkNk3C
Not all web servers consistently handle an HTTP 1.1 Byte Range Request for
"Range: bytes=$length-". Apache responds with 416, but others do not. So to
make us impervious to servers that respond with something other than 416, just
have us not make such a request when we know that the server thinks our
requested range is unsatisfiable.
We make such a request when we reach end of stream for a stream that has been
suspended/resumed. We are now more likely to suspend and resume streams with the
recent changes to our throttling logic.
MozReview-Commit-ID: 6URqzjLglOM
--HG--
extra : rebase_source : bcac7fde91b625e214d7d041c135a211833a1e85
extra : source : 75a37fe77f397576b5bb60d38293f215c815e61a
Because it is already printed by LOG() itself.
MozReview-Commit-ID: 6dBESWQtNkQ
--HG--
extra : rebase_source : 37d1b5360825543a9e28443167219a50adfdebef
It's silly to use prmem.h within Firefox code given that in our configuration
its functions are just wrappers for malloc() et al. (Indeed, in some places we
mix PR_Malloc() with free(), or malloc() with PR_Free().)
This patch removes all uses, except for the places where we need to use
PR_Free() to free something allocated by another NSPR function; in those cases
I've added a comment explaining which function did the allocation.
--HG--
extra : rebase_source : 0f781bca68b5bf3c4c191e09e277dfc8becffa09
A/V sync will be broken for the compositor will render the 1st frame
immediately without considering its timestamp.
MozReview-Commit-ID: 6j7GLccrFcX
--HG--
extra : rebase_source : 924a2404d8d944262d1f8744794a072c051ac556
extra : source : 1e254ff8491084b66dfebbb2e1be03790c95ed11
The problem here is that the server is setting the Content-Length to the size
of the gzipped file, which is confusing our media code as that's not the length
of the decompressed stream. Necko's decompressor is streaming, so we can't know
the length of the stream in advance unless we wait for the entire file to
download first. We also can't seek in compressed HTTP resources anyway.
So just have our code assume that compressed HTTP channels are of infinite
length and have un unseekable transport. Then we can seek in the buffered
regions at least.
MozReview-Commit-ID: 9SiLuMZGSeJ
--HG--
extra : rebase_source : ca561776a684a4a0a39a830ecda499732666daaa
Adds a testcase corresponding to what's happening here; we have a gzipped
file with a Content-Length which is the length of the compressed stream.
MozReview-Commit-ID: 8SDayegP11W
--HG--
extra : rebase_source : 1ae21d0f202e24f6e0236d3f2d2363ab930b0c2e
Most of the names passed to nsIStringBundle::{Get,Format}StringFromUTF8Name
have one of the two following forms:
- a 16-bit C string literal, which is then converted to an 8-bit string in
order for the lookup to occur;
- an 8-bit C string literal converted to a 16-bit string, which is then
converted back to an 8-bit string in order for the lookup to occur.
This patch introduces and uses alternative methods that can take an 8-bit C
string literal, which requires changing some signatures in other methods and
functions. It replaces all C++ uses of the old methods.
The patch also changes the existing {Get,Format}StringFromName() methods so
they take an AUTF8String argument for the name instead of a wstring, because
that's nicer for JS code.
Even though there is a method for C++ code and a different one for JS code,
|binaryname| is used so that the existing method names can be used for the
common case in both languages.
The change reduces the number of NS_ConvertUTF8toUTF16 and
NS_ConvertUTF16toUTF8 conversions while running Speedometer v2 from ~270,000 to
~160,000. (Most of these conversions involved the string
"deprecatedReferrerDirective" in nsCSPParser.cpp.)
--HG--
extra : rebase_source : 3bee57a501035f76a81230d95186f8c3f460ff8e
We detect when a PSSH is contained in a MOOF and stash them in the
mp4_demmuxer::Moof object. When the mp4_demuxer::SampleIterator returns a
sample, we check whether it's the first sample from its MOOF, and if so, we
attach any PSSH boxes from that MOOF to the sample. The TrackBuffersManager
checks samples upon demux, to see whether they have any EME init data attached,
and if so dispatches thoses to the HTMLMediaElement in 'encrypted' events.
MozReview-Commit-ID: F8GobKOr96F
--HG--
extra : rebase_source : 5366f1008979605aa8fc80216cd1d9cc2eefd346
Includes "bear" samples from the Chromium project which include several
runs of PSSH boxes in their MOOF boxes.
MozReview-Commit-ID: 4KIJ2FCOyWT
--HG--
rename : dom/media/test/short-cenc.mp4 => dom/media/test/short-cenc-pssh-in-moof.mp4
extra : rebase_source : 29cd7ea0e3b76935d76e376ee0f88f4c93aca85d
Makes it easier to re-use in the test in the next patch.
MozReview-Commit-ID: 56Gbe8KFSgX
--HG--
extra : rebase_source : 3e2aa140dbf4faad015c1c760fc5b18de396d848
We're not really gaining much information by checking for an upper limit on
the bytesReceived or bytesSent stat here. This should help with
intermittent failures.
MozReview-Commit-ID: 5tPRKlaOYX6
--HG--
extra : rebase_source : fd6c570a5c0ca403e554ade533314bb85dcffa4e
In bug1371202, it has already implemented what I want to do, so remove the
change in bug1367980.
MozReview-Commit-ID: LoH51bBDTqr
--HG--
extra : rebase_source : 9fd77acae81f94e45f0f840775c81509e85c4ad0
Since now MFR doesn't need an AbstractMediaDecoder at all, we can
now remove BufferDecoder which exists as an empty shell to implement AbstractMediaDecoder.
MozReview-Commit-ID: HpEcK0mfpeh
--HG--
extra : rebase_source : e4d58d3b706aaf6ee005b9f82a668dd38efc2200
extra : intermediate-source : caa1e64b1a0216773d31854341075858a8dc2d0f
extra : source : c644912a8eeed0a18d61e11a3bcc92a39a6de483
So we can remove the use of AbstractMediaDecoder::NotifyDecodedFrames().
MozReview-Commit-ID: Ch7Saha6zdi
--HG--
extra : rebase_source : 8562faa56d1f31797643ed0f7ae550765d8c86d7
extra : intermediate-source : 05b50517cc40f2adf06facfccea628488dd319da
extra : source : d5af89f5a09e03c8fbb0d6111f88e3221f3a1d57
Update the MediaRecorder principal test to behave more like
test_mixed_principals.html. This involves preloading metadata and using a
longer video to test with. This particular combination currently results in
multiple requests being made for the resource, however this is not a robust
solution in that the behaviour of the MediaCache and associated objects may
change and break this. This fixes the issue for now as best I can tell, but
a follow up gtest or may be a more sensible long term solution.
MozReview-Commit-ID: F9gnnzGt3Cu
--HG--
extra : rebase_source : 73f56e256c21f5a775e0fa2a32606d7f7553bd4e
The new video decoder in CDM version 1.4.8.970 seems to calculate its frame size
as about 1.5X of the optimal size. So increase our estimate of CDM video frame
buffer sizes by more than that so that our pre-allocated buffers should be big
enough to accomodate the allocations that the CDM requests.
This means we should be more likely to avoid the slow fallback path where we
have to transfer frames from the CDM to the content process using the non-shmem
path.
MozReview-Commit-ID: 6PT8XVCAL3E
--HG--
extra : rebase_source : a27793b033c4f50f6e15d874558dc50e1410c8be
The strategy we were using to expand the pool of shmems we use to shuffle video
frames between the CDM and content processses is to increase the size of the
pool if the content process receives a video frame in a non-shmem. However the
CDM process will send a frame in a non-shmem if none of the shmems in the pool
are big enough to fit the frame the CDM produces. This happens if we
underestimate the size required for video frames. This causes the
ChromiumCDMParent to increase the number of shmems in the pool every time we
rate switch, until we eventually hit the limit of 50, whereupon playback fails.
So we need to disambiguate between these two cases; the first being we have a
pool of shmems, but they're the wrong size, the second being our shmems are the
right size, but we've run out and we need to expand the shmem pool. The only
place where we know this is in the CDM process. So this commit adds a new
message to PChromiumCDM through which the ChromiumCDMChild can report to the
parent that it needs more shmems in the pool.
The new Widevine CDM has a new video decoder which allocates video frames less
optimally than the previous, which causes us to hit this more often in Nightly.
Our telemetry also indicates we hit this rarely in Beta with the old CDM.
MozReview-Commit-ID: LoSvVhxHQxn
--HG--
extra : rebase_source : 6c7201a74dbf202d0ef8c2269292a80a7ad95dff
extra : source : 57cf5455fd14ef0b68b61f914146ff942b5ca4a0
Note we remove the call to mChannel->SetContentType() from RecreateChannel().
The hint never works as expected for [1] is the only caller to
nsIChannel::GetContentType() and MediaResource::Create() always happens
before any reads from the resource.
[1] http://searchfox.org/mozilla-central/rev/b425854d9bbd49d5caf9baef3686e49ec91c17ec/dom/media/MediaResource.cpp#1500
MozReview-Commit-ID: 1n4yHEouCjC
--HG--
extra : rebase_source : 9a7345c29b985ddee7a90a94191e9d526e2a0a67
extra : source : 054d9ffaf21eb937a6349df76228269ad2d7dc2c
So we can remove MediaResource::GetContentType() in the future.
MozReview-Commit-ID: zWUNF2uGpf
--HG--
extra : rebase_source : 04f50c4db9dac8503f878a8a1986e627f9a074a3
extra : source : 10737393beaabed640aa3ff67fac2a07567400b4
Accept av1 video in the webm decoder even when we've determined
the machine is too slow for software vp9 decoding. While we're
at an experimental stage with this codec, poor performance is
preferable to not being able to see a demo at all.
MozReview-Commit-ID: 6DJHCPfXHlA
--HG--
extra : rebase_source : 8fb5c0dac6483abf4775e3546dadd5aaa45947ac
Accept av1 video in the webm decoder even when we've determined
the machine is too slow for software vp9 decoding. While we're
at an experimental stage with this codec, poor performance is
preferable to not being able to see a demo at all.
MozReview-Commit-ID: 6DJHCPfXHlA
--HG--
extra : rebase_source : 0819c3ddd437e9e56b18ba1fc6c56d4bdaebfa77
Chrome supports playback rates in the ranges of [1/16,16], so we may as well
support the same.
MozReview-Commit-ID: 7mMXQfPiv9d
--HG--
extra : rebase_source : 5dd0b717ad711f49ff3df5156cc07d48c8a694b7
Null aStreamListener is passed only when cloning.
Since we remove cloning in P2, we can now remove the call path.
MozReview-Commit-ID: B0vKVy5jsqo
--HG--
extra : rebase_source : a93fad61325d29faa2d45e7c1d3762616ab72cff
It doesn't make much sense to clone a FileMediaResource for they have no data to share.
MozReview-Commit-ID: IoR87DAUCFa
--HG--
extra : rebase_source : eab6c0f013be9e3b1877d29f16c1701f27460578
Also remove CanClone() overrides that are identical to that of the base class.
MozReview-Commit-ID: A0Q5ychQtso
--HG--
extra : rebase_source : 3369558a8e6bc9f86ab6dcdc39fe40f686041001
So we can remove the use of mMutex from InvalidateWithFlags().
MozReview-Commit-ID: 75pHDM5xYYb
--HG--
extra : rebase_source : e39e1a3e4c796b8163b0c9b1bfeec048e6fb06f0
Many video codecs use a suffix to specify level, profile and optional features,
like "avc1.42E001" or "vp09.00.41.08".
MediaCodecs::ContainsPrefix() can be used to facilitate codec identification
from their prefix alone, e.g.: "avc1" or "vp09".
MozReview-Commit-ID: D6kcjggXptS
--HG--
extra : rebase_source : 3a60c01da1d91adf29f51ce3c32f8df60282c90a
For testing purposes, it is useful to pass a null aWindow to the DOMMediaStream
constructor. This limits the amount of code that needs to be mocked to create
a mock media stream.
MozReview-Commit-ID: Jgm1m7N0FU4
--HG--
extra : rebase_source : 90ab0157bd0d75cb53190bf4a5d388971a6fdd1b
So we won't pass an unused |nsIStreamListener**| to MediaSourceDecoder::Load().
MozReview-Commit-ID: 2TCby8m8K5H
--HG--
extra : rebase_source : 349179aa4303c0abd8b86a695789770e158e5c28
extra : intermediate-source : d6f550bd6709a0ee7db6033286af42565a20cdb1
extra : source : ed524d855a1a78665c499152a9360ba961655641
The code couldn't have worked, mNeedSPSForTelemetry can only be set if we didn't get an H264 extradata in the MP4 metadata.
So any calls to HasSPS(sample->mExtraData) would have always returned false.
MozReview-Commit-ID: 3PcRXJHBJyC
--HG--
extra : rebase_source : 5b70a1e40b38b61982264784c489f11ddf9d4682
It was only used in one spot, and incorrectly at that.
MozReview-Commit-ID: EWkkrAlYT7W
--HG--
extra : rebase_source : a19afe8f49e1e0fd430ddbff81978eb3511c5fb5
HasSPS, ExtractExtraData and CompareExtraData have nothing to do with the handling of annex B format. They are raw H264 related methods.
It will also prevent in the following change to have cycling references between two headers.
MozReview-Commit-ID: FCs5aU4GcTU
--HG--
extra : rebase_source : a96fe0c70416d38690b0c2f1dee567b0b025e947
The code couldn't have worked, mNeedSPSForTelemetry can only be set if we didn't get an H264 extradata in the MP4 metadata.
So any calls to HasSPS(sample->mExtraData) would have always returned false.
MozReview-Commit-ID: 3PcRXJHBJyC
--HG--
extra : rebase_source : 4137b9c985ffe7ee3958fad509149bf911229eed
It was only used in one spot, and incorrectly at that.
MozReview-Commit-ID: EWkkrAlYT7W
--HG--
extra : rebase_source : 9c719bbf668eafaac0415580ffdfa0cea0942673
HasSPS, ExtractExtraData and CompareExtraData have nothing to do with the handling of annex B format. They are raw H264 related methods.
It will also prevent in the following change to have cycling references between two headers.
MozReview-Commit-ID: FCs5aU4GcTU
--HG--
extra : rebase_source : b204723cdbb599d4f0a227871ed28f5da39e9cff
This patch makes the following changes to the macros.
- Removes PROFILER_LABEL_FUNC. It's only suitable for use in functions outside
classes, due to PROFILER_FUNCTION_NAME not getting class names, and it was
mostly misused.
- Removes PROFILER_FUNCTION_NAME. It's no longer used, and __func__ is
universally available now anyway.
- Combines the first two string literal arguments of PROFILER_LABEL and
PROFILER_LABEL_DYNAMIC into a single argument. There was no good reason for
them to be separate, and it forced a '::' in the label, which isn't always
appropriate. Also, the meaning of the "name_space" argument was interpreted
in an interesting variety of ways.
- Adds an "AUTO_" prefix to PROFILER_LABEL and PROFILER_LABEL_DYNAMIC, to make
it clearer they construct RAII objects rather than just being function calls.
(I myself have screwed up the scoping because of this in the past.)
- Fills in the 'js::ProfileEntry::Category::' qualifier within the macro, so
the caller doesn't need to. This makes a *lot* more of the uses fit onto a
single line.
The patch also makes the following changes to the macro uses (beyond those
required by the changes described above).
- Fixes a bunch of labels that had gotten out of sync with the name of the
class and/or function that encloses them.
- Removes a useless PROFILER_LABEL use within a trivial scope in
EventStateManager::DispatchMouseOrPointerEvent(). It clearly wasn't serving
any useful purpose. It also serves as extra evidence that the AUTO_ prefix is
a good idea.
- Tweaks DecodePool::SyncRunIf{Preferred,Possible} so that the labelling is
done within them, instead of at their callsites, because that's a more
standard way of doing things.
--HG--
extra : rebase_source : 318d1bc6fc1425a94aacbf489dd46e4f83211de4
Bug 1374173 seems to be the cause of all MediaCache intermittent assertion
failures. It's not an important bug, so let's back-out and verify that
intermittents disappear.
MozReview-Commit-ID: 2X8iW1hWu99
--HG--
extra : rebase_source : e22443a5b9d5ba9a6ce4b126953a880e8e469cd2
On Linux some implementations of time(0) appear to be suffering from integer
overflow and giving us the wrong dates. This causes the time we expose to the
CDM to be wrong, and so licenses passed to the CDM are failing to authenticate,
and Netflix is thus broken on some Linux systems.
This is only happening in Firefox 54 and earlier, as in those versions we use
the WidevineDecryptor to talk to the CDM. In 55 (in beta) and later we use the
PChromiumCDM protocol to talk to the CDM. This doesn't use time(0) to get a
time for the CDM, so it's immune to the problem here.
So this patch makes the GetCurrentWallTime() implementation in
WidevineDecryptor match the code currently being used on Nightly and Beta in
the ChromiumCDMChild::GetCurrentWallTime() function.
Since we use the PChromiumCDM protocol to talk to the CDM on Nightly and Beta
by default, the WidevineDecryptor isn't actually being used on Nightly and
Beta. So this patch will only cause a behaviour change in Release, which still
uses the old backend. However it will make Release run the same code that we're
running in Nightly and Beta, so it should be safe to uplift to Release.
MozReview-Commit-ID: J58iDyinyQG
--HG--
extra : rebase_source : dcdf4a846f7b007526aa626db24598942f13f01d
All the instances are converted as follows.
- nsSubstring --> nsAString
- nsCSubstring --> nsACString
--HG--
extra : rebase_source : cfd2238c52e3cb4d13e3bd5ddb80ba6584ab6d91
This patch gives some structure and order to the profiler's API.
It also renames AutoProfilerRegister as AutoProfilerRegisterThread, to match
profiler_register_thread().
We also move some methods to protected so they are callable from ChannelMediaDecoder.
MozReview-Commit-ID: 6s9LKNkbJhX
--HG--
extra : rebase_source : 172ea88bc01552a90f5ef51db2b5af0ac5551c3b
extra : intermediate-source : a724333159c6b408e2fa68dba2d0a467f3c55940
extra : source : 03760e05ea8044b3404d29bb62205a2f62892d4b
Bug 1368837 (Add lockless cache to MediaResourceIndex) used
MediaResource::ReadFromCache when trying to fill its local cache. But this
meant that these reads would not count as "real reads" for the MediaCache,
which could lead to unexpected states, e.g. "Played block after the current
stream position?"
To solve this, this patch reverts to using normal ReadAt() calls, which let
the MediaCache update itself properly.
While still trying to read more than what is requested (to hopefully fulfill
future reads from the local cache), we don't want to be reading so much that
we block waiting for data past the caller-expected point.
To do this, MediaResourceIndex::UncachedRangedReadAt() is called to try and
read as much as could fill the local cache, but if a single
MediaResource::ReadAt() ends before we can fill the local cache, but *after*
the minimum caller-requested size, we stop trying to read, as such extra read
is at risk of blocking (assuming that the caller knows not to read too far.)
MozReview-Commit-ID: 6fGvJpmkuLz
--HG--
extra : rebase_source : bf8e9f20599a05c8f3f221b55d678f0b5da447a9
