HlsSampleStream#read should return end of stream when
there is no mapping for the sample stream, instead of
nothing read. This allows the player to transition to
ended.
Issue:#5524
PiperOrigin-RevId: 234764027
This bug affects any playlist that uses initialization segments. In practice,
almost exclusively fragmented mp4 segmented playlists are affected.
The bottom line is that extractors are chosen for reuse after the
initialization segment connection is open. However, reused extractors
do not need re-parsing the init segment, so loading the initialization is
wasteful.
PiperOrigin-RevId: 234479467
This requires to prepare the media source and the periods in a small helper similar
to the metadata retriever. It also gets rid of the need to have abstract protected
methods to load the manifest, to extract the track groups and to convert to stream keys,
as this can now be handled by the media period.
PiperOrigin-RevId: 231385590
Currently, we remove all variants if none of the stream keys contains any
variants. This causes HlsMediaPeriod to throw exceptions as it expects at least
one variant.
Change it to support master playlists without variants.
PiperOrigin-RevId: 231385547
That's the same position set in MediaPeriod.prepare (where it may be removed
in the future).
Having the position at an earlier point is necessary to fix an
issue with lazy preparation in ConcatenatingMediaSource where the prepare
position was assumed to be known but MediaPeriod.prepare hasn't been called
yet.
Issue:#5350
PiperOrigin-RevId: 229756637
They are not longer needed anywhere, are error-prone (because of threading
requirements), and complicate testing and using MediaSources without a player.
PiperOrigin-RevId: 227871157
* Add AC-4 MIME type definition
* Add AC-4 format support in Mp4Extractor and TsExtractor
* Add AC-4 Extractor
* Add AC-4 playback support in MPEG-4, MPEG-DASH, TS and HLS
- Enable GZIP for media playlist + encryption key chunk requests in
HLS, as we do during playback
- Pass around DataSpecs rather than Uris. This will be needed for if
we add manifest cacheKey support (which seems like a good idea for
completeness, if nothing else)
PiperOrigin-RevId: 224057139
Moving most of the logic to the base DownloaderHelper helps to implement track
selection for downloading in a single place instead of multiple places.
PiperOrigin-RevId: 223964869
A remove action will eventually just be the unique ID of the download
that should be removed. This is a step toward that goal.
PiperOrigin-RevId: 222832456
The input.getLength() check is invalid because the length may be
unknown (i.e. if the server doesn't include a Content-Length
response header when serving chunks).
Issue: #5063 (tangentially related only)
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222406347
1. Pull up all subclasses of DownloadAction into DownloadAction
2. Add DownloaderFactory for Downloader instantiation, and DefaultDownloaderFactory
to replace the instantiation logic being removed from the DownloadAction
subclasses.
This change will upgrade existing action files gracefully (i.e. it does not
lose compatibility with the existing offline implementation, other than some
minor breaking changes to the API).
TODOs:
1. Move test methods from the XDownloadActionTest classes into DownloadActionTest.
This will be done in a subsequent CL. There's a lot of consolidation that can
be done here, including de-duplicating some of the test code added in this CL.
2. Look at merging DownloaderConstructorHelper into DefaultDownloaderFactory.
3. Use customCacheKey in DASH/HLS/SS Downloaders, for completeness.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222258983
This makes extractor selection a bit more efficient for some CMAF files.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=219795105
