H264 decoders always use those anyway, so may as well use them in the demuxer if SPS NAL is available.
This guarantees that we have correct dimensions when reading the MP4 metadata, and will have the side benefit that when loadedmetadata is fired, the dimensions provided at the time will be final; not having to wait to decode the first frame.
MozReview-Commit-ID: 3j70Xqw8jJY
--HG--
extra : rebase_source : 6bc0f1fa1c2db35bcaa683cc1a68042d122e2892
Extracted from the H264 codec and using the stagefright one.
MozReview-Commit-ID: ENjsDvB9MYp
--HG--
extra : rebase_source : 51b92215622df8cdcb65453013ab8022923dd9e8
Run the updated import script to split the in-tree byteorder
code into a separate directory and build it as a dependent crate.
MozReview-Commit-ID: EI5X4icOdmM
--HG--
extra : rebase_source : fa0d4cce8503ede5d2fbefc4d4b78735f2140c33
Now that bug 1231764 has landed cargo support in the build system,
we can remove the patches hacking the byteorder crate into a
module within the mp4parse crate.
This updates the import script to copy the byteorder source
files to a separate directory and removes the obsolete patches.
We update the patch against mp4parse/Cargo.toml to add a dependency
path referring to the new source location. This tells cargo to use
the in-tree copy instead of trying to pull from a registery.
MozReview-Commit-ID: FHMkyEq2HdH
--HG--
extra : rebase_source : 49e893008bb120740da92e81444a4bd43f3265d4
This patch is really two separate changes.
The first change is that rust crates are large, standalone entities that
may contain multitudes of source files. It therefore doesn't make sense
to keep them in SOURCES, as we have been doing. Moving to use cargo
will require a higher-level approach, which suggests that we need a
different, higher-level representation for Rust sources in the build
system.
The representation here is to have the build system refer to things
defined in Cargo.toml files as the entities dealt with in the build
system, and let Cargo deal with the details of actually building things.
This approach means that adding a new crate to an existing library just
requires editing Rust and Cargo.toml files, rather than dealing with
moz.build, which seems more natural to Rust programmers. By having the
source files for libraries (and binaries in subsequent iterations of
this support) checked in to the tree, we can also take advantage of
Cargo.lock files.
The second is that we switch the core build system over to building via
cargo, rather than invoking rustc directly.
We also clean up a number of leftover things from the Old Way of doing
things. A number of tests are added to confirm that we'll only permit
crates to be built that have dependencies in-tree.
This patch is really two separate changes.
The first change is that rust crates are large, standalone entities that
may contain multitudes of source files. It therefore doesn't make sense
to keep them in SOURCES, as we have been doing. Moving to use cargo
will require a higher-level approach, which suggests that we need a
different, higher-level representation for Rust sources in the build
system.
The representation here is to have the build system refer to things
defined in Cargo.toml files as the entities dealt with in the build
system, and let Cargo deal with the details of actually building things.
This approach means that adding a new crate to an existing library just
requires editing Rust and Cargo.toml files, rather than dealing with
moz.build, which seems more natural to Rust programmers. By having the
source files for libraries (and binaries in subsequent iterations of
this support) checked in to the tree, we can also take advantage of
Cargo.lock files.
The second is that we switch the core build system over to building via
cargo, rather than invoking rustc directly.
We also clean up a number of leftover things from the Old Way of doing
things. A number of tests are added to confirm that we'll only permit
crates to be built that have dependencies in-tree.
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
Make Cargo.toml, build.rs and standard cargo source package
layout available in-tree to facilitate testing cargo-driven
builds of rust code.
Update the moz.build script to build using plain rustc as
before, but referencing the new source location.
MozReview-Commit-ID: 11zuebic9tU
--HG--
extra : rebase_source : 1cb71896ae5dd33d1237ca04ec27da60b2256dad
Both the WebM and mp4 demuxers need to pack this value into
the the CodecSpecificConfig, so move the shared implementation
to the OpusDecoder, near where it is unpacked so the two can
be kept in sync.
MozReview-Commit-ID: 2pQaruJoAWr
Remove patches for issues which are fixed upstream.
Update the script to generate the C api header file by running
`cargo build` before copying it.
Update byteorder mod-ification patch to apply to 0.5.3.
MozReview-Commit-ID: 8FDpbcSWt1o
Update C++ caller code for for mp4parse 0.4.0. Now feeds data through
a read callback in mp4parse_io.
Hook up the GetTrackInfo method to the rust demuxer results.
Prefer rust demuxer only if there's an Opus track.
Fill in audio and video track metadata. Pass audio codec_specific_config
to the decoder.
With this change sample.mp4 plays.
MozReview-Commit-ID: F8xwWPZZBfZ
Remove patches for issues which are fixed upstream.
Update the script to generate the C api header file by running
`cargo build` before copying it.
Update byteorder mod-ification patch to apply to 0.5.3.
MozReview-Commit-ID: 8FDpbcSWt1o
Update C++ caller code for for mp4parse 0.4.0. Now feeds data through
a read callback in mp4parse_io.
Hook up the GetTrackInfo method to the rust demuxer results.
Prefer rust demuxer only if there's an Opus track.
Fill in audio and video track metadata. Pass audio codec_specific_config
to the decoder.
With this change sample.mp4 plays.
MozReview-Commit-ID: F8xwWPZZBfZ
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
Wes Kocher
Jean-Yves Avenard
Ralph Giles
Nathan Froyd
Kaku Kuo
Carsten "Tomcat" Book
Tom Tromey
Alexandre Lissy
Phil Ringnalda
Jonathan Watt
Kilik Kuo
Chris Peterson
Ryan VanderMeulen
Jeff Muizelaar
Sebastian Hengst
Nathan Froyd