The test uses either a theora/flac file or a h264/mp4 one.
XP doesn't have a h264 decoder and as such the test would have failed in
the past having no file to work with.
This is no longer the case now that flac in ogg is usable.
MozReview-Commit-ID: EWUR4G85XPD
--HG--
extra : rebase_source : aecd4d8759ad23096a671c81880923edf7283c36
Considering its popular use, the decision to support this format was agreed upon.
MozReview-Commit-ID: Dcwr547dbW
--HG--
extra : rebase_source : ea49578dcc81bf483015fc5a9ab9598011004163
This only supports flac with a STREAMINFO header.
MozReview-Commit-ID: FaT9N6xJDPY
--HG--
extra : rebase_source : ba4e1f78f3a3ca9b4062edfc84445d444c323d80
We also move flac related files to their own flac folder.
MozReview-Commit-ID: YnV3HNbjZe
--HG--
extra : rebase_source : 5f064723d68a877d9790f0c51c5d1579d7a9bac4
Extracted from the H264 codec and using the stagefright one.
MozReview-Commit-ID: ENjsDvB9MYp
--HG--
extra : rebase_source : 293d8e184cc7b326e6b84d038fd98ff94703f31e
When the content is served by Apache, a file with an .aac extension always see its Content-Type set to x-aacp.
MozReview-Commit-ID: 65NANlKNQek
--HG--
extra : rebase_source : 5f5d4bf65117f862a22698b450dedd2d5f0ef8d1
This feature is intended to debug the flac parser only and is behind a hidden pref.
There's lots of redundant code in OggCodecState, there's need for a serious cleanup there.
MozReview-Commit-ID: 9H4efd2cfuE
--HG--
extra : rebase_source : cd5f6d16dd319391a0469b8317a18ef1d5e58331
Make it just like MP4, WebM and all the others new demuxers.
Additionally, make the ogg related preferences part of MediaPrefs.
MozReview-Commit-ID: DTedHyIMv9I
--HG--
extra : rebase_source : 8bfdf971993281454776a7c4fa644c9fc7c5ee8c
The code was designed around the need for a MediaResource::Read which is
no longer possible since bug 1190238
MozReview-Commit-ID: 7s76YWg93jS
--HG--
extra : rebase_source : 3f6756193c352cf766471dd8cb1fb7646af191e6
The MP4 demuxer returns INT64_MAX when all data can be safely evicted
from the MediaResource.
Additionally, the MP4Demuxer will read the MediaResource using
CacheReadAt.
Eviction in the SourceBufferResource had a safeguard to ensure we would
never evict data we hadn't read yet. This was done by keeping the
position of the last data read in the mOffset member. CacheReadAt
however doesn't update mOffset.
As a result, no data was ever removed from the input buffer when using
MP4.
MozReview-Commit-ID: 2tAWzpMlOjG
--HG--
extra : rebase_source : bec585ca46e7fd0665c00bce525aaacede1b3897
With raw streaming flac, we can't determine the audio format at the time the codec is opened.
Additionally, when using streaming flac, we do not have a STREAMINFO block. The FFmpeg flac decoder check that extradata is null and not its size and would error due to an invalid extradata.
MozReview-Commit-ID: KZ3n8b8WUMo
--HG--
extra : rebase_source : a0dd8f517d730b1414c6461fc5c5e5b08d0d8b10
Change test files to specify the mime type of the file. This is checked
by media test manager so that changes in mochitest.ini are not needed.
MozReview-Commit-ID: 4hFQmRknBOY
--HG--
extra : rebase_source : b76a8dfe071dec320a7ebef8fc071e671278c1fa
This new version of the schema validates that numeric values are
within an acceptable range (i.e. are not infinite)
MozReview-Commit-ID: 32oT39Bfcwg
--HG--
extra : rebase_source : 78ef5402e47e05f3f4e5a1db7b36e2d365c7b13b
Bubble information from SamplesWaitingForKey to an HTMLMediaElement so that we
can emit a waitingForKey event. If we are unable to decode more samples due to
needing a key the event will be signalled. See
http://w3c.github.io/encrypted-media/#dom-evt-waitingforkey for more information
on this event.
The code in place before this patch handles updating readyState when we are
waiting for a key, this patch adds the event which should be emitted in such a
case. The spec defines certain preconditions should be the case before running
the algo to emit this event. For example, the element should potentially be
playing, and it should have at least HAVE_FUTURE_DATA ready state. This is not
strictly true for when the new code is run, due how existing code handles ready
state. We are honoring the spirit of the spec, though the letter of the spec is
lightly gone against in the handling of the preconditions.
MozReview-Commit-ID: LKlDd4wkRSE
--HG--
extra : rebase_source : 2c61fc41636e430afa23240ad5d26c886124d87f