- 01 Oct, 2018 2 commits
-
-
Extend Sony workaround up to and including Oreo. Due to a platform issue the Display API couldn't report 1080p UI and 4k SurfaceView support until Oreo. Since Oreo it is still common for devices to misreport their display sizes via Display, so this change switches to using system properties up to and including Pie. On Pie treble may prevent writing sys.display-size so check for vendor.display-size instead. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=214987203
andrewlewis committed -
This makes the annotations appear in the generated JavaDoc. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=214952419
tonihei committed
-
- 27 Sep, 2018 13 commits
-
-
More specifically, if the parts of the Format that are used for decoder configuration are unchanged. Issue: #2826 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=214791234
olly committed -
Oliver Woodman committed
-
r2.9.0
ojw28 committed -
Oliver Woodman committed
-
If a source is removed from the playlist, the player may still call createPeriod for a period of the removed source as long as the new timeline hasn't been handled by the player. These events are stale and can be ignored by using a dummy media source. The stale media period will be released when the player handles the updated timeline. Issue:#4871 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=214787090
tonihei committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=214784773
andrewlewis committed -
If a source is removed from the playlist, the player may still call createPeriod for a period of the removed source as long as the new timeline hasn't been handled by the player. These events are stale and can be ignored by using a dummy media source. The stale media period will be released when the player handles the updated timeline. Issue:#4871 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=214787090
tonihei committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=214784773
andrewlewis committed -
Issue:#4861 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=214772527
aquilescanta committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=214750185
aquilescanta committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=214650418
cblay committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=214638939
cblay committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=214598078
aquilescanta committed
-
- 26 Sep, 2018 5 commits
-
-
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=214584874
aquilescanta committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=214584874
aquilescanta committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=214582295
eguven committed -
This simplifies code skipping items in a playlist programatically. Issue:#4863 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=214580742
tonihei committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=214277073
aquilescanta committed
-
- 24 Sep, 2018 9 commits
-
-
Issue: #4834 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=214258163
olly committed -
Issue: #4857 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=214254231
olly committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=214227045
andrewlewis committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=213979058
olly committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=214261973
eguven committed -
Issue: #4834 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=214258163
olly committed -
Issue: #4857 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=214254231
olly committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=214227045
andrewlewis committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=213979058
olly committed
-
- 21 Sep, 2018 11 commits
-
-
This method needs to be called whenever the track selection of the current loading period changes, but also when the loading period itself (and thus the "loading track selection") changes. These are the same situations in which we update the loading media period id and thus we can move both updates in a common helper method. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=213959982
tonihei committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=213951977
olly committed -
From API 23 this uses the timed format queue. Before API 23 the format is notified as soon as the buffer is queued. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=213830729
andrewlewis committed -
Before this change we would reset the start trim to zero after initial configuration (at the start of playback) and after seeking to any position. The fact that no trimming was applied at the start of playback meant that after the first period transition we'd see a mismatch between the next buffer timestamp (equal to the duration of the period taking into account edits) and the duration of audio submitted to the sink. This change modifies the behavior so that we reset the start trim to zero only if some audio was queued since configuration. This is incorrect in the case of starting playback at a non-zero position, but fixes the common case of starting at zero. As before, a later seek to any position is handled via a flush and resets the trim as required. Transitions from one period to the next are unaffected by this change. One way to implement start trimming correctly would be to provide the input buffer timestamp to the audio processors and only trim when handling audio from the start of the stream, but that is a larger change so left for later. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=213828511
andrewlewis committed -
Also fix internal build by adding some methods. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=213828434
andrewlewis committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=213824217
andrewlewis committed -
After a period transition the first buffer queued has the sum of previous period durations added to its source presentation timestamp. These durations take into account gapless edits, but the check on the timestamp was based on the submitted frame count, not the frame count after trimming. This change fixes an issue where audio/video would gradually drift apart due to accumulated error in the audio track position, which could lead to freezing due to the audio renderer stopping being ready and switching to the standalone media clock. Issue: #4559 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=213819908
andrewlewis committed -
This method needs to be called whenever the track selection of the current loading period changes, but also when the loading period itself (and thus the "loading track selection") changes. These are the same situations in which we update the loading media period id and thus we can move both updates in a common helper method. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=213959982
tonihei committed -
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=213951977
olly committed -
From API 23 this uses the timed format queue. Before API 23 the format is notified as soon as the buffer is queued. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=213830729
andrewlewis committed -
Before this change we would reset the start trim to zero after initial configuration (at the start of playback) and after seeking to any position. The fact that no trimming was applied at the start of playback meant that after the first period transition we'd see a mismatch between the next buffer timestamp (equal to the duration of the period taking into account edits) and the duration of audio submitted to the sink. This change modifies the behavior so that we reset the start trim to zero only if some audio was queued since configuration. This is incorrect in the case of starting playback at a non-zero position, but fixes the common case of starting at zero. As before, a later seek to any position is handled via a flush and resets the trim as required. Transitions from one period to the next are unaffected by this change. One way to implement start trimming correctly would be to provide the input buffer timestamp to the audio processors and only trim when handling audio from the start of the stream, but that is a larger change so left for later. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=213828511
andrewlewis committed
-
