This flag was introduced to workaround a rounding error in Chrome
(probably in other browsers too).
Also although this flag avoids the first frame of a Period to be
dropped due to rounding error but it could cause the last frame of a
Period to be dropped.
Now that we use a high precision Period@duration, we do not expect to
see rounding errors any more. The player would be a better place for
the workaround even if it is still needed.
Related issue: #368.
Change-Id: I3bd517ecc6d548ff62e0c13394edb49d4bc68e8f
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
Chrome internally uses time accurate to microseconds, which is
implemented per MSE spec (https://www.w3.org/TR/media-source/).
Generate Period@duration with better precision to avoid possible
buffered range gaps in Chrome (possibly other browsers too), which
may lead to other problems like playback stall.
b/74238961
Fixes#368.
Change-Id: I357a0f62b67f75c7ca044bb99ea4e3c8bbb6fecd
Prefer timestamps from Video AdaptationSets if available - this avoids
possible video playback jitters due to gaps.
presentationTimeOffset is not applied to the first period as it may in
negative dts which Chrome does not like: https://crbug.com/398141.
It is safe to apply to subsequent periods as the actual offset applied
takes Period@start into consideration:
offset = Period@start - presentationTimeOffset
The result timestamp with offset applied is close to Period@start, so
it is unlikely to result in a negative dts value.
Closes b/73899306.
Change-Id: If8361f5469610093b3aac6675754536ad7e83c4c
- Implemented according to v1.0 spec @ https://www.webmproject.org/vp9/mp4/
- v0 is no longer supported
Change-Id: I189c813d788400beda797eea7da943a83dfa7d79
- Added flag --mp4_include_pssh_in_stream, default to true. If it is
set to false, the encrypted mp4 stream will not include pssh.
- Align BytesOfProtectedData to multiple of 16 bytes for cenc.
- Set TrackHeader flag to kTrackEnabled | kTrackInMovie |
kTrackInPreview
- Move mvex to after trak, required by HLS
- Add cmfc/cmfs compatible brands except for avc3/hev1, where CMAF
requires single initialization switching set which is not supported.
- Set duration to 0 in tkhd, mdhd, mvhd.
Also updated major_brand and compatible brands:
- Set major_brand to isom (iso-bmff media file format) and made dash
a compatible brand
- Replaced compatible brand iso6 with iso8 since we use sthd for text
tracks
Fixes b/36278260
Change-Id: I3cc5dd5aa1621714d517fe02fe3841d19a1a07f6
This will move ContentProtection element from Representation
to AdaptationSet.
Shaka Player already supports AdaptationSet switching
urn:mpeg:dash:adaptation-set-switching:2016;
ExoPlayer does not support it yet. Filed
https://github.com/google/ExoPlayer/issues/2431 to track the issue.
(ExoPlayer does not like having ContentProtection in Representation
anyway)
Closes b/34691105
Change-Id: I69d0a4d0e15a912a35c8b2686620419a28e4cc99
- Added two new fields in MpdOptions: dash_profile and mpd_type
- Updated MpdBuilder to support LiveProfile with static mpd
- Command line arguments will be updated in the next CL
Issue #142
Change-Id: Ibd35e5c9e1b1ef98043392e3f04a0af4700135c1
KongQun Yang