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
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
JW Wang
Masatoshi Kimura
Jeff Walden
Jean-Yves Avenard
Tom Tromey
Florian Quèze
Bevis Tseng
Gerald Squelart
Wes Kocher
Andrew McCreight
Nathan Froyd
Ralph Giles