Also clear the playingPeriodHolder in the case the renderers
are being disabled. This is required to ensure that
setPlayingPeriodHolder isn't turned into a no-op, which will
break the seek.
Issue: #2330
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=144635220
This overrides the start position relative to the window.
Issue:#1544
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=144434903
ClippingMediaPeriod may be a useful component for other MediaSources too so
remove its dependency on ClippingMediaSource.
Also allow the clipping end point to be TIME_END_OF_SOURCE, in which case
the clipping window extends to the end of the wrapped period.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=144056285
These currently lead to cryptic ArrayIndexOutOfBoundsExceptions being thrown from System.arraycopy() so my proposal is to throw a more useful ParserException instead.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=142087132
- If there's no program-date-time then this change is
a no-op.
- If there is a program-date-time this change considers
the period as having started at the epoch rather than
at the start of the content. The window is then set
to start at the start of the content. This is a little
weird, but is required so that the period sample
timestamps match the start of the period. Note that
this also brings the handling of on-demand in line
with how the live case is handled, meaning there wont
be weird changes if a live stream changes into an
on-demand one.
Issue: #2224
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=142442719
Also clarify when getNextLoadPositionUs and continueLoading
can be called.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=142124497
ClippingMediaSource wraps a single period/window video-on-demand source and
exposes a specified time range within it.
Issue: #1988
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=141991215
This is particularly problematic for subtitle tracks where adjustment
can be broken. Now, the primary url can change when clients ask for a
variant snapshot, instead of happening on chunk load as before.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=141933689
This requires knowing the seek time in Extractor.seek, so that it's possible to
pick the latest synchronization sample at/before the seek time for each track
(rather than the earliest synchronization sample after the seek position).
Also remove the STATE_AFTER_SEEK state which should no longer be needed.
Issue: #2167
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=141432598
When the primary url is blacklisted (due to a 404, for example) or
the selected variant is different from primary url, allow the tracker
to change the url.
Issue:#87
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=141291435
Pending improvement:
* Peek just the required priv frame. Avoid decoding all id3 information.
* Sniff the used container format instead of using the extension.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=141181781
These additions are useful for sources that need to track the playback position
and control playback.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=140828310
This allows ID3 PRIV timestamp extraction and Extractor Sniffing.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=140209568
Select the timestamp master depending on track availability. If
a variant is being loaded, then that is the timestmap master.
Otherwise, if an audio track is being loaded, then the responsible
chunk source is the timestmap master. If no variant or audio
rendition is enabled, then a subtitle chunk source is selected as
timestamp master. This CL will become specially relevant once
ID3 PRIV timestamps are used for audio renditions.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=140201385
The refresh handler in HlsPlaylistTracker was being instantiated in the
same thread as the MediaSource (i.e. Main thread).
Issue:#2108
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=140197553
This issue affects ExtractorMediaSource only. We shouldn't
start loading in the case that we're prepared and have no
enabled tracks, since there's nothing that we need to load.
This was causing an assertion failure in startLoading.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=140030650
Note that multi-segment fetching is only possible in the
case that segments in a representation are defined to have
the same Uri and adjacent ranges (this is very rarely true
for live streams, but is quite often true for on-demand).
In the case that merging is requested but not possible,
the implementation will request one at a time.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=140012443
Also allow custom DashManifestParser injection, to
support parsing of custom elements and attributes that
service providers may wish to include in their manifests
(e.g. #2058).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=139813108
This is techically not allowed by the spec[1] but might still occur in
certain scenarios. New playlists with older media sequence numbers are
ignored.
[1]: HLS draft version 20, section-6.2.1
Issue:#2059
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=139564889
continueLoading shouldn't return true unless it's done
something. Always returning true if endOfStream was
causing CompositeSequenceableLoader.continueLoading to
loop forever.
It looks like the same issue exists in ChunkSampleStream
as well, although I can't seem to provoke DASH or SS
playbacks into doing anything bad as a result.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=139559834
This is the first step towards allowing discontinuities in the
playlist tracking. Also changed durationSecs for durationUs in
MediaPlaylist.Segment.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=138207732
A VOD-style period in a dynamic manifest would result in a NullPointerException.
Also fix another issue in which an unrecognized mime type would also result in
NullPointerException.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=138075137
