We have a minimum requirement of VS 2015 for Windows builds, which supports
the z length modifier for format specifiers. So we don't need SizePrintfMacros.h
any more, and can just use %zu and friends directly everywhere.
MozReview-Commit-ID: 6s78RvPFMzv
--HG--
extra : rebase_source : 009ea39eb4dac1c927aa03e4f97d8ab673de8a0e
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
We will remove MediaDecoderReader in the future.
MozReview-Commit-ID: BaCRXleKK5a
--HG--
extra : rebase_source : dc14a593d6291136f02b1deb910cd6dcd01c0355
extra : source : 8f71b7dae0a541562c7c3829b5a873e9f9fd2674
We waited 30s until we changed readyState to HAVE_ENOUGH_DATA this would cause autoplay media element to start rather late. In particular with live stream. 10s is typically enough ahead time to start playback.
MozReview-Commit-ID: LJvY8cQYfwZ
--HG--
extra : rebase_source : 4c75326891ba4e9317c432ea7074eb033a77b300
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
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
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
So we are able to dispatch NotifyDataArrived() to MediaDecoderReader in P2.
MozReview-Commit-ID: 3RM66uTvYSc
--HG--
extra : rebase_source : 40311cf27fefbd2046016fb246a3a4ccfce845a8
extra : source : 515d9b3b3cd4b0b30d2fd8196b48c55e14466263
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
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
Also remove CanClone() overrides that are identical to that of the base class.
MozReview-Commit-ID: A0Q5ychQtso
--HG--
extra : rebase_source : 3369558a8e6bc9f86ab6dcdc39fe40f686041001
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
We also move NotifyDownloadProgressed() to private
since it won't be called outside MediaDecoder.
MozReview-Commit-ID: GISbJEW7wwx
--HG--
extra : rebase_source : a454e1477ad645e9e2ee9cab8b31332b38518836
extra : source : 8ca5e3e1fac96a150e5df8e4d06c11f85ee3257d
All former users of the old MP3 parsing code are gone, so we can now just remove the parser itself as well.
We also need to fix up an include issue in AutoTaskQueue.h that was previously masked by MP3FrameParser.cpp through unified builds.
MozReview-Commit-ID: CtvmfJKq5or
--HG--
extra : rebase_source : 73fe84244b4286c1eddce01c3001e3f985c8c568
We will add more fields to MediaDecoderInit and be able to remove some setters.
MozReview-Commit-ID: BVx935IHQHf
--HG--
extra : rebase_source : 6d167265e478ce39881ceada1303e9ca18189bbf
extra : source : 0c26f909568f673591ad6720458dfc912c01daad
This hint will inform readers if caching is discouraged (e.g., for
SourceBufferResource) or recommmended (e.g., for MediaCache-backed
ChannelMediaResource).
MozReview-Commit-ID: 7hopNS0s5tE
--HG--
extra : rebase_source : 681646cc904229e8513adb148baa085254508049
MediaResourceIndex caching requires GetCachedDataEnd and ReadFromCache.
Implementing SourceBufferResource::GetCachedDataEnd is trivial, as it's just a
buffer from 0 to GetLength(), so if the requested cached-data offset is inside
the buffer, we can just return the total length as known cached data.
MozReview-Commit-ID: 1DO0PzDnjQp
--HG--
extra : rebase_source : e7a652622221c04e77dc3a3b7707f22e1db25599
A SourceBufferResource is only ever used on the same taskqueue. It doesn't require to be thread-safe.
MozReview-Commit-ID: HREUvzaHyD9
--HG--
extra : rebase_source : dfa9d5223e892f95091fb522a1d768167d874a0a
I'm not sure what this mochitest was supposed to test, but it was doing it wrong anyway.
MozReview-Commit-ID: BexSN7YgXwj
--HG--
extra : rebase_source : ee056ab1eede9381376265dffb2f171cec87b086
Per spec loadedmetadata should be fired before updateend. fetchAndLoad want on the updateend event. So we can't wait for the loadedmetadata event only after updateend has been fired.
MozReview-Commit-ID: BprzynZ8t1U
--HG--
extra : rebase_source : e3281b2d68272f5dd08567bfd3189e75411a6a99
MSE specs require that the readyState be modified during either the Initialization Segment Received or the Coded Frame Processing algorithms.
At this stage, we only handle the Initialization Segment part (readyState moving from HAVE_NOTHING to HAVE_METADATA)
MozReview-Commit-ID: KBnnWuHJ6Om
--HG--
extra : rebase_source : a4450139762d5d033438fbee2ce560fe02ed6ffc
It was incorrect to assume that once "loadeddata" event fired the sourcebuffer would be usable again. Only the "updateend" event guarantees such condition.
MozReview-Commit-ID: HcyaLWjjBlp
--HG--
extra : rebase_source : c9d7a91ecc40c633078eaa2dec635e240106dff6
The stalled event can be fired as playback is starting and data has yet to be processed.
So instead we wait for playback to reach the end.
MozReview-Commit-ID: 4W3M5tee2HD
--HG--
extra : rebase_source : 349321452f8e1cc3307e8cedb6ebf44949694661
When endOfStream() is called, the duration is changed to that of the last buffered frame's end time.
The ended event will only be fired if currentTime is equal to the duration. So if the duration has changed following a call to endOfStream, then playback won't be considered as ended.
MozReview-Commit-ID: DBu3LorwFTI
--HG--
extra : rebase_source : a721ac0186f609b23537b71819c63d812f89a3b6
We have no need to call endOfStream here as we don't rely on the ended event being fired.
Also, there's no need to track how many update count we will get when we only use appendBuffer once.
Adding extra test to help identify where the actual failure of the test could occur.
MozReview-Commit-ID: HIu1XQpHark
--HG--
extra : rebase_source : 07f9ac856d290f1347ec4b33794dc7d20adcc4cc
Assuming that the buffered range has been updated when loadedmetadata was fired was wrong. Only once the data has been fully appended to the source buffer, can seeking complete.
MozReview-Commit-ID: LRY0PRaMEw9
--HG--
extra : rebase_source : 07dcae199c8c38e3cadc3c4ed302e4bd3a82b48b
StoreCopyPassByRRef<> ensures a copy is stored in the runnable.
We don't have to worry about the concern of bug 1300476.
MozReview-Commit-ID: DHqlzlVLBFV
--HG--
extra : rebase_source : 77f2175611aa6fad88207a771de75fd28fd46f21
extra : source : 429c62928fd43185da45c905a150cfbe84cb3cf7
We want to replace the use of int64_t for microseconds by TimeUnit
whenever possible since int64_t is ambiguous which could be microseconds
or milliseconds.
MozReview-Commit-ID: K3Bz3uEXLDK
--HG--
extra : rebase_source : ade3cbd61c764b73a22c360572a525127dbadbc5
extra : intermediate-source : 013227a4aa645fc34a82c44130db6c847d74960b
extra : source : 1ab7ce426b557e4ce9979e023f9e84b4690eeaaa
1. using media::TimeUnit to save some typing.
2. replace TimeUnit() with TimeUnit::Zero().
3. replace TimeUnit::FromXXX(0) with TimeUnit::Zero().
4. replace TimeUnit::FromMicroseconds(std::numeric_limits<int64_t>::max()) with TimeUnit::FromInfinity().
5. replace some uses of int64_t with TimeUnit.
6. replace t > TimeUnit() with t.IsPositive().
MozReview-Commit-ID: 6hC94PXx86i
--HG--
extra : rebase_source : 1ea3b409e6ec12915f3e1a00359d6ff4152c8917
extra : intermediate-source : e31a12ad0e7a4840119036f261ed17eaaff85734
extra : source : ae07ee48000c4a52da0e4fd502b4d690ec51ce1f
If 'media.playback.warnings-as-errors' is true, demuxing and decoding warnings
(i.e., non-fatal errors) will be treated as errors, causing playback to fail.
Currently set to false by default.
This could be later changed to catch and diagnose more issues.
MozReview-Commit-ID: BTaZ6TbIbNG
--HG--
extra : rebase_source : bacc24a46f588dd344e6d46178ae2d2c58882fcb
Similarly to the MediaFormatReader, TrackBuffersManager can forward warnings
from the demuxer initialization to the associated HTMLMediaElement.
Note that errors (sent to OnDemuxerInitFailed) are currently *not* forwarded
to the HTMLMediaElement by design. In the future, we may want to add this
feature so that mediasource errors can also be reported to webcompat.
MozReview-Commit-ID: GjluZbpmC9q
--HG--
extra : rebase_source : 57c02f86c56f054f209094d9697209300acc1288
By ISOBMFF spec, an init segment is made of an ftyp and a moov box. However the ftyp box serve little purpose as such and only the moov atom contains essential information.
Some streams incorrectly add ftyp box all accross the content, despite the ISOBMFF spec stating (4.3.1):
Box Type: `ftyp’
Container: File
Mandatory: Yes
Quantity: Exactly one (but see below)
Additionally, with this change the ftyp box may not be present in content following earlier spec. So we will now be able to play them.
MozReview-Commit-ID: KijlV5pPLby
--HG--
extra : rebase_source : c5d5ec643879b28b3fdf1b97364d856467ba5948
The init and media segment byte ranges were not offset by the amount of bytes currently parsed. Whenever a new init segment signature was seen we would recreate a container parser.
This would lead to invalid offsets later.
MozReview-Commit-ID: 8U7kTa7SK8O
--HG--
extra : rebase_source : 6b6e665e01db2685a423558b2d09ce36b9052974
See bug 853398 for the reason to block double multiplier which is slower and
less precise for large values. Also we remove the friend functions of
operator* because it is easy to cause overloading ambiguity when making
them templates.
MozReview-Commit-ID: FhIWSHDd41b
--HG--
extra : rebase_source : e9fec65dfb0b077dd7f962eb20af719c0dc76df8
Add an AVC3 (content provided by BBC) mochitest. We've regressed BBC playback rather regularly. Better make sure this never happens again.
MozReview-Commit-ID: 5ssaLcqiqsv
--HG--
extra : rebase_source : 27938e746822f89167f287d57c81f276198b2c5e
Note the race is uncovered by P1 which kinda change the order of events.
MozReview-Commit-ID: 3INYvJVUhSG
--HG--
extra : rebase_source : e378c2a437a5a729008d39570be2a9087a7eb5f7
extra : intermediate-source : 02e2ecfea068dd9f487791287064e684a15dd599
extra : source : f2f40c70a2304e3e499422f3a7c46b59b54ad1ae
This patch is generated by the following sed script:
find . ! -wholename '*/.hg*' -type f \( -iname '*.html' -o -iname '*.xhtml' -o -iname '*.xul' -o -iname '*.js' \) -exec sed -i -e 's/\(\(text\|application\)\/javascript\);version=1.[0-9]/\1/g' {} \;
MozReview-Commit-ID: AzhtdwJwVNg
--HG--
extra : rebase_source : e8f90249454c0779d926f87777f457352961748d
into TrackInfoSharedPtr to better indicate what this class is about.
Adding cast operator to allow transparent conversion from TrackInfoSharedPtr to const TrackInfo*
MozReview-Commit-ID: 6RwXl5CG0fG
--HG--
extra : rebase_source : b5a7a0f06793c609e2eab60aacc4f76d96d6ec32
See see bug 1321198 comment 17. This is a workaround to alleviate the issue
which seems to happen on win8 x64 opt only.
MozReview-Commit-ID: Lr4viEjuFkC
--HG--
extra : rebase_source : 99895cf6f6f13d5f4d698f76db7acda15d8cee77
Continuing the work of replacing MIME strings with MediaContainerType, starting
from MediaResource and following the dependencies.
Most changes are mechanical: Just change ns*String into MediaContainerType, and
MIME string literals into MEDIAMIMETYPE("a/b").
Some checks for empty/invalid strings and lowercase comparisons can go, thanks
to the always-valid always-lowercase-MIME invariants of MediaContainerType.
One special case in is MediaSourceResource, which used to have an empty string
as its type (because its own type is not relevant, but its SourceBuffers carry
types). Because the inherited GetContentType *must* be overridden, and must
return a MediaContainerType, we needed a valid type even though it should not
be seen in the real world. I've chosen "application/x.mediasource" for that.
MozReview-Commit-ID: 1aCH75Kh2e6
--HG--
extra : rebase_source : 0d9cd9b69c264e5dcfc3845f80ee107f4bcbcd9a
Partial content less than 8 bytes long was incorrectly rejected.
We now assume that content is valid unless it is explicitly incorrect (bad box type)
MozReview-Commit-ID: 8L32mNVjzxh
--HG--
extra : rebase_source : 980242aab96d5b96dc7e62ad289e8ecd7b228032
Now that we have move all data-handling functions to MediaMIMEType and friends,
we can remove direct accesses to data from MediaContentType, to better separate
the context that MediaContentType represents, from the data it includes.
Dependent code needs to be mechanically updated to now use the proper APIs.
Note that in most places, we just extract MIME strings. Further work will take
place in later bugs, to completely replace these strings with MediaContentType
or more appropriate types...
MozReview-Commit-ID: LoX8dhX7OlB
--HG--
extra : rebase_source : cf221ac3c104f99b36cfa055afcf67d3bca26d0e
Bug 1176218 made IsTypeSupported return a DOMTypeError if the type cannot be
parsed, but this was incorrect.
This was not important until now, because the basic parser accepted invalid
MIME types and therefore would never report an error there.
But the next couple of patches will introduce a stronger check that will
refuse types other that "application/...", "audio/...", and "video/...", and
would now trip the web-platform tests.
MozReview-Commit-ID: EeyFnyurEZK
--HG--
extra : rebase_source : 76f831ddc3c19e0d820454f6f949d44e15d6773c
Now that we have move all data-handling functions to MediaMIMEType and friends,
we can remove direct accesses to data from MediaContentType, to better separate
the context that MediaContentType represents, from the data it includes.
Dependent code needs to be mechanically updated to now use the proper APIs.
Note that in most places, we just extract MIME strings. Further work will take
place in later bugs, to completely replace these strings with MediaContentType
or more appropriate types...
MozReview-Commit-ID: LoX8dhX7OlB
--HG--
extra : rebase_source : 63eba419e5cb8a69500008145769c8e4ef99f33f
MediaContentType can only be created through MakeMediaContentType(), which
returns a Maybe<MediaContentType>.
If the return value is Nothing, parsing failed.
Otherwise the contained MediaContentType object is guaranteed to be valid;
E.g., GetMIMEType() will always return a non-empty string.
Note that this interface will change a lot in the following bugs&patches, so
please don't worry about the 'Get' in the never-failing GetMIMEType(), it will
be gone soon!
MozReview-Commit-ID: IjGKkQ6RVd4
--HG--
extra : rebase_source : 5254af80dec0beb05da49f68c12fecc28edd725e
This is done by storing the object pointer based on the exact pointee type,
instead of as hinted by the method-pointer, which could be a non-refcounted
base class.
The stored pointer type is statically-checked to be derived from (or the same
as) the class type from the method-pointer, to prevent misuses.
One change had to be done in TrackBuffersManager, as it was passing another
type and relying on implicit pointer conversions. A simple `.get()` to pass
the raw pointer type (to be stored in a RefPtr) fixed that one issue.
MozReview-Commit-ID: 4kH0XdjB5Rk
--HG--
extra : rebase_source : 40ad68820cfce469ecda272f430062f05dfcd09f
This is done by storing the object pointer based on the exact pointee type,
instead of as hinted by the method-pointer, which could be a non-refcounted
base class.
The stored pointer type is statically-checked to be derived from (or the same
as) the class type from the method-pointer, to prevent misuses.
One change had to be done in TrackBuffersManager, as it was passing another
type and relying on implicit pointer conversions. A simple `.get()` to pass
the raw pointer type (to be stored in a RefPtr) fixed that one issue.
MozReview-Commit-ID: 4kH0XdjB5Rk
--HG--
extra : rebase_source : 3eb7fa3cb1873f71b4d5e7118d2dc48f6fdf2874
Under some cases YouTube attempts to append more than 10MB of data ahead of currentTime. This causes the appendBuffer to be rejected with QUOTA_EXCEEDED_ERR as as per spec.
Bug 1320829 slightly increased the size of the MediaRawData object (by 36 bytes) which on average caused an increase of 470kB of the source buffer size causing the eviction threshold to be crossed quicker.
YouTube clears the entire source buffer once a buffer full is reported and reloads it all, causing an audible silence.
Bumping the threshold slightly is the only way to get around the problem.
MozReview-Commit-ID: HgtHFcZHUG1
--HG--
extra : rebase_source : 74b78a551c5eb827576d1797928cc4da51eb3dd1
We don't generate timestamps for ADTS but we can verify
the Init Segment Range and Media Segment Range returned
by the parser match the frame size declared in the
Init Segment header.
MozReview-Commit-ID: FCZfxn9b69R
--HG--
extra : rebase_source : 44e6f842b815fcc1f21c3b2425a729f3773af319
This should be bitwise OR rather than logical OR, which just
returns 1. This code has clearly never worked, but it isn't
currently called.
MozReview-Commit-ID: 9Iuy7a7P85O
--HG--
extra : rebase_source : 4da35a507993ee761ac952259c1be3a974a8a0ac
