Commit Graph

7 Commits

Author SHA1 Message Date
KongQun Yang 1223694249 Do not force earliest_presentation_time to 0 for VOD
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
2018-04-20 13:58:01 -07:00
KongQun Yang 668335c647 Generate a more accurate time in Period@duration
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
2018-04-20 13:39:40 -07:00
KongQun Yang e1bb27f130 Integrate CueAlignmentHandler
Also changed ChunkingHandler to be one-one handler.

Issue: #355

Change-Id: Ie98a96bcc0ddded347699c9f333f604826976d11
2018-03-27 16:48:08 -07:00
KongQun Yang f8a1cb66ad Calculate presentationTimeOffset and Period@duration from segments
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
2018-03-01 22:25:55 -08:00
KongQun Yang 1455f43c02 Share chunkers from the same input except for WVM
Updated test files and added end to end tests for AdCues.

Change-Id: I28f57c2f0d15f65fa04f599fae446a5c1373bf47
2018-01-22 17:43:25 -08:00
Kongqun Yang d007ddf20b [MP4] Make outputs CMAF compatible
- 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
2017-03-30 15:33:39 -07:00
Kongqun Yang bee59bc2fc Enable generate_dash_if_iop_compliant_mpd by default
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
2017-02-09 11:12:21 -08:00