We don't currently support H.264 on Android in automation, but we can improve
our test coverage by running the VP8 portion of this test in the meantime.
MozReview-Commit-ID: 3SPCTaqlfMk
--HG--
extra : rebase_source : cae3251f489e45f56b04378074083d6b4fd24666
This happens when the listener and a PannerNode are at the same position, and
a cone gain has been specified.
The issue is that our implementation of 3d vector normalization does not
special-case vectors that have all components at zero, that dividing by zero
results in infinity, and multiplying by infinity produces NaN.
This end up setting the volume member for the output AudioChunk to NaN, and this
breaks everything downstream, of course. In practice, silence is output, with
some clicks (on linux/pulse at least).
MozReview-Commit-ID: 8u54LixvYMu
--HG--
extra : rebase_source : 3b37970b42e5c60cd6e39d3197b580edc63b5ac9
No change is needed for MediaCacheStream::Read() which calls |mon.Wait()|
and has handled changes when dropping the monitor.
MozReview-Commit-ID: 40h0cHn1WFx
--HG--
extra : rebase_source : 5447339ed7751f3171458d8e5fb1e5f6fe3a786e
We don't want to do IO while holding the monitor which might be acquired
on the main thread in MediaCache::Update().
MozReview-Commit-ID: 4cHM35K8Twb
--HG--
extra : rebase_source : 5a00332933abd1812f64fa57c9f5e2947ec979ae
In addition to the returned MediaResult, a special number-of-tracks value
(not just 0) indicates an unrecoverable error.
For Rust-vs-Stagefright comparison purposes, an error is considered the same
as 0 (because Stagefright never returns errors, but Rust may, so complaining
about that would be too noisy, and useless to us.)
MozReview-Commit-ID: IwadWSOIWr4
--HG--
extra : rebase_source : 29f53ee6a02a0431adb0b615a122a4e7b480108c
The returned MediaResult is used as error or warning in MP4Demuxer::Init().
MozReview-Commit-ID: Bnv4xG8bCJ4
--HG--
extra : rebase_source : c1952ed61396834b0cd7da58c9b64481a5c46ab1
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
The MediaFormatReader now takes the MediaResult from the Demuxer::Init promise
resolution, and if there are no other errors but the MediaResult is not NS_OK
it will forward that warning to the decoder owner (i.e., the associated
HTMLMediaElement).
MozReview-Commit-ID: 5rTmzqqPLI0
--HG--
extra : rebase_source : 5f81db185a01c012bf0418af2a42986db14a7e6f
If MP4Demuxer::Init detects some recoverable error (e.g., invalid tracks when
others may still be usable), it will eventually Resolve the promise with the
first warning.
Later on, errors/warnings from the MP4Metadata parser will also be handled, to
provide even better diagnostics.
MozReview-Commit-ID: E9Rly9dhXW3
--HG--
extra : rebase_source : cae214d0c80297bd61156dc1a305a186da0974fe
In case of successful initialization, there could still be some warning about
a recoverable error. To carry more information about this potential warning,
the resolve-value type of the promise is changed from nsresult to MediaResult.
Existing code doesn't need to be changed:
- In Resolve() calls, the stored MediaResult can implicitly be constructed from
an nsresult -- always NS_OK at the moment anyway.
- In following Then(), the promise's MediaResult can implicitly be converted to
an nsresult.
Future patches will modify some of the Resolve's and Then's, to forward warning
details to some Decoder Doctor object...
MozReview-Commit-ID: J0bXDFxXQHQ
--HG--
extra : rebase_source : cb10cdfa80e34783a459e5946b746b9f1920bd87
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
