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
A small optimization found while working on the previous patch.
MozReview-Commit-ID: 4w2LI5mqUvS
--HG--
extra : rebase_source : 70b9ad73c57da5079df607b5176fcfa45ed42e81
Thanks to the previous patch, MediaDataDemuxer::Seek and
SkipToNextRandomAccessPoint (and all overrides in derived demuxers) can now
take their TimeUnit parameter by const&.
MozReview-Commit-ID: 6CqfjAXZ7Yk
--HG--
extra : rebase_source : c3453e4432d9e0281cf5eba55217b0c1d6312f5b
We now take a copy of the TimeUnit object, and can then pass it by rref to
internal methods.
MozReview-Commit-ID: J0Idw85NMcu
--HG--
extra : rebase_source : 9cb8dd45ff7b449074121df8618ee7295398138b
An invalid webm block at this stage is either a non init segment or non media segment.
MozReview-Commit-ID: 46NrhCwqas1
--HG--
extra : rebase_source : b5be124fc0789cfe0fe757c5fb83f18a769a8bd4
This still requires all the ContainerParser to be updated in properly handling errors.
MozReview-Commit-ID: A7gDmXSJXmc
--HG--
extra : rebase_source : c438fdd40deb843e43f341d107e48171141dc746
Previously two separate monitors were used to find the highest end time, and then work on tracks, introducing the possibility that tracks could be modified between these two operations. Now only one monitor is used to ensure consistency.
MozReview-Commit-ID: 1foB82S6W1Z
--HG--
extra : rebase_source : 817ff8cf231372a4db90b2c11f3bb60d1031fa89
Replace both uses of nsContentTypeParser with MediaContentType.
MozReview-Commit-ID: KV7ze3ASRf3
--HG--
extra : rebase_source : b3d102b02fa671d0a42d70ae7fe66bdd51ac5d86
It's write only, so there's no point storing this, and it's not accurate
anyway, as it's actually tracking whether there's encrypted init data in
the media, not whether its got encrypted tracks.
MozReview-Commit-ID: 78iFUyXwRBV
--HG--
extra : rebase_source : f500b90d32da042a550172128a4c79c142048a98
extra : amend_source : c4e31f686e2c0f2c400225919c45c3a530373a8c
While never evicting less than 512kB saves CPU cycles, it reduces the chances to evict data when we actually need to and requires currentTime to advance much further.
MozReview-Commit-ID: LcQFFtarbbi
--HG--
extra : rebase_source : 381de3d926bbb12377f4332eb87c08b52a56551a
