This reverts bug 1255869 which added a runtime check for sse2
support to work around sse2 instructions in the rust standard
library targeting i686-pc-windows-msvc.
We now make official builds against i586-pc-windows-msvc which
should omit the sse2 instructions which aren't supported for
all our current users.
Per ISO 14496-12, the Track fragment decode time (tfdt) is optional.
MozReview-Commit-ID: LNrMPYlkDvt
--HG--
extra : rebase_source : fbacde893352db9248a3ebe6a62b2042eb3106b6
Work around sse2 instructions in the rust standard library
built for the i686-pc-windows-msvc target. We disable
sse2 code generation for our own code.
MozReview-Commit-ID: F6n0CmBd8dQ
Instead of relying on some arbitrary limit for ftyp+moov box sizes, we check
for overflow and possible type truncations, and then let memory allocation
routines (e.g. MediaByteBuffer::SetLength) deal with actual memory limitations.
MozReview-Commit-ID: AXXxvdDYnnr
Initializing in the constructor better matches libstagefright's behaviour
(and avoids reading and copying the stream contents every time
GetNumberTracks() is called).
Also restricts the size of the buffer to 1MB. This will be handled in the
future by passing the parser a DataSource-like interface for reading from
the stream.
Most of the interface is stubbed with asserts and only GetNumberTracks() is
called on both libstagefright and mp4parse-rust variants.
This also moves the libstagefright vs mp4parse-rust comparisons up into
MP4Metadata.
This is temporary (until libstagefright is removed) and intended to make
swapping between and comparing the results of the libstagefright and
mp4parse-rust versions simpler.
As of mp4parse 0.2.0 error codes are positive, as gecko telemetry
requires, so we no longer need to invert them. However, the return
code is still signed, so assert to catch future errors.
Also fix a bug in track comparison telemetry. We were only counting
tracks when parsing failed.
If we can get this to work it will be less confusing, I think.
Byteorder has to be in a subdir while we're treating it as a mod.
We may have to add yet another directory when we have crate support
but until then all the rust code is at least self-contained..
--HG--
rename : media/libstagefright/binding/byteorder/mod.rs => media/libstagefright/binding/mp4parse/byteorder/mod.rs
rename : media/libstagefright/binding/byteorder/new.rs => media/libstagefright/binding/mp4parse/byteorder/new.rs
rename : media/libstagefright/binding/capi.rs => media/libstagefright/binding/mp4parse/capi.rs
rename : media/libstagefright/binding/MP4Metadata.rs => media/libstagefright/binding/mp4parse/lib.rs
We now use an index of samples made of block of samples delimited by keyframes. The search is performed using a binary search. This allows to quickly find which blocks are found within the media cache.
On a 8 core mac pro, this leads to a 67% improvement on CPU time spent playing a long MP4 video (from 112s CPU to 45s CPU)
The optimisation is only possible if all mp4 data chunks are continuous (which they almost always are)
- Made externally-sized 'new' allocations fallible.
- Check return value of every new(fallible)/malloc/realloc.
- Consistently return -ENOMEM when allocations fail.
- MPEG4Extractor::getTrack() and getMetaData() can return null (because of
failed parse or failed alloc); added missing checks in callers.
Note: Some allocs in the 2nd half of MPEG4Extractor have not been touched, as
they are in unused code to be removed in bug 1210319.
Use the new LazyLogModule to instantiate a log for the rust
mp4parse test code instead of using indiscriminate printf()s.
Access results with NSPR_LOG_MODULES=MP4Metadata:5.
Add a helper for passing the initialization segments
of mp4 streams to the rust parser and log the result.
This runs real data through the new parser for testing
but doesn't use the results.
Code is conditional on MOZ_RUST_MP4PARSE to be defined
in confvars.sh. See bug 1219530.
Ralph Giles
Jean-Yves Avenard
Gerald Squelart
Louis Christie
Rudolfs Bundulis
Birunthan Mohanathas
Phil Ringnalda
Matthew Gregan
Wes Kocher
sajitk