Commit Graph

8 Commits

Author SHA1 Message Date
KongQun Yang b31fc75eb6 Use max bitrate in Representation@bandwidth instead of average bitrate
According to DASH spec (23009-1:2014):

Consider a hypothetical constant bitrate channel of
bandwidth with the value of this attribute in bits per second
(bps). Then, if the Representation is continuously delivered
at this bitrate, starting at any SAP that is indicated either by
@startwithsap or by any Segment Index box, a client can
be assured of having enough data for continuous playout
providing playout begins after @minbuffertime *
@bandwidth bits have been received (i.e. at time
@minbuffertime after the first bit is received).
For dependent Representations this value specifies the
bandwidth according to the above definition for the
aggregation of this Representation and all complementary
Representations.

This suggests that max bitrate should be used instead of average
bitrate.

Also cleaned up BandwidthEstimator code.

Fixes #376.

Change-Id: Ibf5896394c5c6bb820849771a2129c59202d2273
2018-04-20 14:26:52 -07:00
KongQun Yang a6352d4b11 Remove pto_adjustment flag
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
2018-04-20 14:01:14 -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 221ac81772 Prefer Period@duration for static MPD with >1 periods
It is easier to insert Ad Periods with Period@duration compared to
Period@start.

Change-Id: Ib52e81612562bf60b0e0513a09d9a31c42b09604
2018-02-07 01:13:28 +00:00
KongQun Yang d76ccea46f [DASH] Support multiple period
Change-Id: Ifd17bf0eabbd61ec7a1d35f0b864b5aa6666aa87
2018-01-11 21:44:18 +00:00
KongQun Yang ef2c424876 Implement Representation::GetDurationSeconds
Also added Period::GetAdaptationSets and
AdaptationSet::GetRepresentations.

Instead of implementing GetDurationSeconds in all MpdBuilder classes
(MpdBuilder/Period/Adaptation/Representation) like what we used to do
with GetEarliestTimestamp, the two new functions allows MpdBuilder to
iterate through the Representations to get durations.

Also updates GetEarliestTimestamp functions to use the same iteration
method.

Change-Id: I682b70c07c248c0f6511ec3d9019086f986ee10e
2018-01-09 01:03:05 +00:00
KongQun Yang 718fce068d Refactor DashIopMpdNotifier Part 2
Move AdaptationSet related functions to the new Period class, which
maps to <Period> element and provides methods to add AdaptationSets.

Change-Id: I0fee290769fbe9a6355cc1b8c86baec8fbc4b4fd
2017-12-22 13:24:38 -08:00
KongQun Yang 86d960bea6 Move AdaptationSet, Representation out of mpd_builder.h
Change-Id: I61fffb4d956f189b44c7537ddcf183bbf4129840
2017-12-14 21:28:06 +00:00