We had two potentials rounding issue occurring. The one causing the problem is that adding an int64 with a float is a float, and would be limited to 24bits mantissa.
The other, could be that rounding would occur if the segment duration was over 16s long, as that too would exceed the representation range as we using microseconds representation internally.
MozReview-Commit-ID: FyBTGvfg25I
--HG--
extra : transplant_source : %D0%14u%E3%1E%C6%D2%FC4%A4%2B%C0%20k%05%E8%90qz%2B
My guess is that the application generating those files, does a very rough estimate on what the sample table size is going to be, which allows to perform the conversion in a single pass. This allows to place the moov box at the beginning.
MozReview-Commit-ID: IGzxTho4Akk
--HG--
extra : rebase_source : b6ca711a00f8b2d7d8708acdd17f52f59b469685
We think thread::spawn() may be panicking in low memory
conditions. Test this by using the fallible thread::Builder
API and converting spawn Results into an error return.
MozReview-Commit-ID: 36pDaWsR2p8
--HG--
extra : rebase_source : 058273473564fa4c3b3da4cbd231efd9003a7d05
We've audited this code, so the calls inside the closure should
be panic-free. Meanwhile the thread join() itself seems to be
panicing on windows. This will at least get us a more obvious
crash.
MozReview-Commit-ID: JXoDOOu2x0K
--HG--
extra : rebase_source : 661da4e8e8dc98e25b318a51c49a406ee86beb46
Our copy of STLport on Android is so old, it doesn't have support for
vector<T>::data(). The standard defines vector<T>::data() in terms of
vector<T>::front(), so this change should work everywhere.
--HG--
extra : rebase_source : 862d8745b49f48eadf026cbbddf20da7da2d0404
extra : source : 4e5db23bc712948e7371d69438033c03de29a00a
Our copy of STLport on Android is so old, it doesn't have support for
vector<T>::data(). The standard defines vector<T>::data() in terms of
vector<T>::front(), so this change should work everywhere.
CTS are adjusted so that all frames within a moof are contiguous and gapless. This means that the duration of each sample are updated accordingly. In MP4, the definition of a sample's duration is the delta between two decoding timestamp. As such, when changing the duration, the decode timestamp should be updated accordingly.
MozReview-Commit-ID: 8D8DeNeyzy
Our copy of STLport on Android is so old, it doesn't have support for
vector<T>::data(). The standard defines vector<T>::data() in terms of
vector<T>::front(), so this change should work everywhere.
This adds support for parsing AOT audio specific config (which contains extended channels layout).
MozReview-Commit-ID: 7yNGBEAI7sv
--HG--
extra : rebase_source : 6f29c04f1f29785ba097d64df13794f80672fb50
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
We just don't care about it in our use.
Additionally, gmtime and strftime are not thread safe at all (they use global static internally)
MozReview-Commit-ID: HfRpCyx4MpK
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
