Pull from google/ExoPlayer dev-v2 #2
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
[Problem] PAINT-ON mode is not implemented. From the compliance tests: * RDC command has no effect except to select paint-on style. * Next data are written directly to the display upon receipt. * If other captioning is already on the screen, the four-row limit is still in effect. [Solution] It is a rare use case, we do not support overriding characters in existing cueBuilders as PAINT-ON would require. But several compliance tests check if the screen is cleared when the mode switch happens. We must keep the old captions when switching to PAINT-ON mode [Test] - Live Over-the-Air content, beginning of commercials often uses PAINT-ON mode
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
This is in line with how Player.EventListener and AnalyticsListener methods are defined and helps to only implement the callbacks needed. PiperOrigin-RevId: 223991262
We currently default to not caching data if the content length cannot be resolved once the DataSource has been open. The reason for this is to avoid caching progressive live streams. By doing this we were accidentally not caching in other places where caching is possible, such as DASH/SS/HLS segments during playback if the server doesn't include a Content-Length header. Also HLS encryption key chunks, which were very unlikely to be cached during playback because we explicitly set FLAG_ALLOW_GZIP (which normally stops content length from resolving) without setting FLAG_ALLOW_CACHING_UNKNOWN_LENGTH. It seems like a good idea to flip the default at this point, and explicitly disable caching in the one case where we want that to happen. PiperOrigin-RevId: 223994110
PiperOrigin-RevId: 224048465
- 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
PiperOrigin-RevId: 224114911
This instantiates the renderers and extract the capabilities. None of the known renderes incurs any overhead during instantiation. PiperOrigin-RevId: 224118511
PiperOrigin-RevId: 224166374
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.