This work was done over ~80 individual commits in the `cmake` branch,
which are now being merged back into `main`. As a roll-up commit, it is
too big to be reviewable, but each change was reviewed individually in
context of the `cmake` branch. After this, the `cmake` branch will be
renamed `cmake-porting-history` and preserved.
---------
Co-authored-by: Geoff Jukes <geoffjukes@users.noreply.github.com>
Co-authored-by: Bartek Zdanowski <bartek.zdanowski@gmail.com>
Co-authored-by: Carlos Bentzen <cadubentzen@gmail.com>
Co-authored-by: Dennis E. Mungai <2356871+Brainiarc7@users.noreply.github.com>
Co-authored-by: Cosmin Stejerean <cstejerean@gmail.com>
Co-authored-by: Carlos Bentzen <carlos.bentzen@bitmovin.com>
Co-authored-by: Cosmin Stejerean <cstejerean@meta.com>
Co-authored-by: Cosmin Stejerean <cosmin@offbytwo.com>
This converts all time parameters to signed, finishing a cleanup that
was started in 2018 in b4256bf0. This changes the type of:
- timestamps
- PTS specifically
- timestamp offsets
- timescales
- durations
This excludes:
- MP4 box definitions
- DTS specifically
This is meant to address signed/unsigned conversion issues on arm64
that caused some test cases to fail.
Change-Id: Ic752a20cbc6e31fea6bc0894d1771833171e7cbe
- EditLists in input files are parsed and applied to sample timestamps.
- An EditList will be inserted in the ISO-BMFF output if
- There is an offset between the initial presentation timestamp (pts)
and decoding timestamp (dts). Chrome, as of M67, still uses dts in
buffered range API [1], which creates various problems when buffered
range by pts does not align with buffered range by dts. There is
another bug in Chrome that applies EditList to pts only [2]. This
means that we can insert an EditList to align pts range and dts range.
- MediaSamples have negative timestamps (e.g. for Audio Priming).
You may notice the below change on some contents:
- Some media duration is reduced by one or two frames. This is because
EditList in the input file was ignored in the previous code, so video
streams start with a zero dts and a non-zero pts; the smaller of dts
and pts was used as the starting timestamp (related to the earlier
workaround for Chrome's dts bug), so the calculated duration was
actually a bit larger than the actual duration. Now with EditList
applied, the initial pts is reduced to zero, so the media duration is
also reduced to reflect the actual and correct media duration.
It may also result in negative timestamps in TS/HLS Packed Audio, which
will be addressed in a follow up CL.
Fixes#112.
Partially address b/110782437.
[1] https://crbug.com/718641, fixed but behind MseBufferByPts.
[2] https://crbug.com/354518. Chrome is planning to enable the fix for
[1] before addressing this bug, so we are safe.
Change-Id: I59317740ad3807ca66fa74b3a18fdf7f32c96aeb
It was implemented to workaround Chromium's DTS
https://crbug.com/398130, but the workaround does not really work in
all situations.
Remove it now as we already have another workaround available.
Change-Id: I291f559d78120fb743a6679b7d927e5bbc5b6b4e
EPT (earliest presentation time) may be adjusted not to be lower than
the decoding timestamp (dts), but the adjustment should only be done
on the first file when there is one file per Representation per Period.
The second file and onwards should not be adjusted otherwise a GAP
would be created.
Closes#384
Closes b/78517422
Change-Id: I56771ad8fbbe6a87b832ec58854cfbf37d5f1817
Instead, the actual earliest presentation time is used except for
the first segment if there is an offset between presentation time
(pts) and decoding time (dts).
Chrome (as of v66) reports dts instead of pts in buffered ranges in
MSE API. To avoid breaking Chrome, the earliest_presentation_time
of the first segment is set to its dts as Chrome does not like negative
values for
adjusted dts = dts + Period@start (0 for the first period)
- presentationTimeOffset (earliest_presentation_time).
Fixes#303.
Change-Id: I5ca80e05d5570961400499436f2bcc01f06e69e0
In prep for changes to Trick Play, we want to make all messages
copy on write so that if the same message is sent to multiple
handlers, it is not possible for one handler to change the data
another handler is using.
Change-Id: I554166ca11c532412e4dfced5603972ca24dc2bb
Also moved MediaHandler output validation to Initialize instead.
This CL also addresses #122 with consistent chunking.
Change-Id: I60c0da6d1b33421d7828bcb827d18899e71884ce
This flag is needed to workaround the Chromium bug
https://crbug.com/398130, which uses decoding timestamp
in buffered range.
Closes#113
Change-Id: Ib8f18be7165dd968bdc36c18ce29f694235c0c26
This is part of the effort to support Opus in iso-bmff #83.
Changes in this CL:
- Add support for multiple SampleGroupDescription and SampleToGroup
boxes in TrackFragment box;
- Add support for SampleGroupDescription and SampleToGroup boxes
in SampleTable box;
- Add support for AudioRollRecoveryEntry in Sample Group and 'roll'
sample grouping type;
- Also fix a bug that default length was not set correctly in
SampleGroupDescription when constant iv is used.
Change-Id: I7e31386ea6cd17a8ee5e1dca4c1a90937d51368f
This is a follow up to previous CL.
Generated using command:
find {media,app,mpd} -type f -exec sed -r -i 's/#include "(.*)"/#include
"packager\/\1"/' {} \;
common.gypi and mpd.gyp are also modified to take the path change into
consideration.
Change-Id: I1fb102b4eb73ae5fde5f4ab303a12cec09b05c33
Joey Parrish
Joey Parrish
KongQun Yang
Haoming Chen
Aaron Vaage
Jacob Trimble