- 01 2月, 2018 7 次提交
-
-
由 tonihei 提交于
GitHub:#3498 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=183369041
-
由 aquilescanta 提交于
Issue:#3747 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=183366339
-
由 tonihei 提交于
GitHub:#3498 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=183253017
-
由 hoangtc 提交于
When SsMediaSource loads Manifest, it dispatches loadCompleted event even when the load is cancelled. This change makes sure SsMediaSource dispatch loadCancelled event instead. GitHub: #3754 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=183241940
-
由 andrewlewis 提交于
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=183238240
-
由 hoangtc 提交于
Since AspectRatioFrameLayout supports zoom mode as another resize_mode, PlayerView's resize mode xml attribute should include this as well. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=183237663
-
由 eguven 提交于
Helper class to create notifications for downloads using DownloadManager. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=183225948
-
- 25 1月, 2018 6 次提交
-
-
由 olly 提交于
- This gives LoadControl enough information in shouldContinueLoading to know whether returning false will result in a terminal non-playback state. - DefaultLoadControl will always return true when returning false will result in a terminal non-playback state, unless the target buffer size is exceeded. This can help to avoid getting stuck in the case that a MediaPeriod is providing samples from an unexpected starting time. - Make the terminal state actually terminal. Previously the player would end up in an indefinite buffering state. We now fail with an error. - Also remove the opportunity for LoadControl implementations to livelock playback. No sane LoadControl should simultaneously tell the player that it doesn't want to load anything and that it doesn't want to start playback. So this change removes the opportunity and starts playback in EPII instead in this case. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=183114797
-
由 aquilescanta 提交于
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=183102837
-
由 olly 提交于
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=183098172
-
由 aquilescanta 提交于
Try to delay failure for as long as possible. That is, propagate DRM session failures only after an encrypted buffer arrives or clear sample playback without session is not allowed. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=183076348
-
由 aquilescanta 提交于
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=183068548
-
由 andrewlewis 提交于
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=183065262
-
- 24 1月, 2018 27 次提交
-
-
由 Oliver Woodman 提交于
-
由 Oliver Woodman 提交于
-
由 ojw28 提交于
add support in mediacodecaudiorenderer for 24bit pcm to float
-
由 ojw28 提交于
Improve raw resource data source (recreated)
-
由 olly 提交于
Issue: #1606 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=183058160
-
由 olly 提交于
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=183056883
-
由 andrewlewis 提交于
Track the expected next ad group index so that it can be used as a fallback if IMA does not notify the ad index via a LOADED event. Also do some miscellaneous minor cleanup (including logging all LOG events, and logging at debug level where appropriate). ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=183048612
-
由 eguven 提交于
setBytesRemaining() doesn't work when called after closeCurrentSource() ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=182999254
-
由 eguven 提交于
These parsers can be used to get a manifest which includes only the representations identified by the given keys. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=182932874
-
由 tonihei 提交于
So far this wasn't possible because Robolectric's Looper and MessageQueue implementations have multiple shortcomings: 1. The message loop of new HandlerThreads is an not an actual loop and scheduled messages are executed on the thread the message is enqueued (not the handler thread). 2. The scheduler used to replace the message queue is synchronizing all its methods. Thus, when a test attempts to add messages to a Handler from two different threads, it may easily run into a deadlock. 3. The scheduler doesn't correctly emulate the order of messages as they would be in an actual MessageQueue: a. If the message is enqueued on the handler thread, it gets executed immediately (and not after all other messages at the same time). b. The list of messages is always re-sorted by time, meaning that the order of execution for messages at the same time is indeterminate. 4. Robolectric's SystemClock implementation returns the current scheduler time of the main UI thread. So, unless this scheduler is used to add messages in the future, the SystemClock time never advances. This CL adds two helper classes which extend and replace Robolectric's ShadowLooper and ShadowMessageQueue. 1. We intercept messages being enqueued or deleted in the message queue. Thus Robolectric's faulty scheduler gets never used. Instead, we keep a blocking priority queue of messages, sorted first by execution time and then by FIFO order to correctly emulate the real MessageQueue. 2. We also keep a list of deleted messages to know which messages to ignore when they come up in the looper. 3. When a new Looper is started, we override the dummy loop to an actual eternal while loop which waits for new messages, checks if they haven't been deleted, and runs the messages (similar to what Robolectric's MessageQueue would have done at this point). Because we don't actually use the main UI thread in our tests, we can't rely on the SystemClock to progress in any sensible manner. To overcome this issue, we can use the auto-advancing FakeClock also used for the simulation tests. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=182912510
-
由 tonihei 提交于
This achieves two things: 1. All our tests use the same type of assertions. 2. The tests currently run as instrumentation test can be moved to Robolectric without changing the assertions. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=182910542
-
由 eguven 提交于
Instead of DefaultBandwidthMeter, TransferListener<? super DataSource> is used. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=182785785
-
由 tonihei 提交于
These were caused by two issues: 1. The FakeMediaSource can be updated with a new timeline. The setNewSourceInfo is called from a different thread than prepareSource and both access local variables without synchronization. 2. For multi-window playback, the FakeRenderer claims that isReady and isEnded are both set to false if it read the end of the stream. However isReady should be true because it is able to "render" its data until the end of the stream. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=182785169
-
由 andrewlewis 提交于
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=182770109
-
由 hoangtc 提交于
When a loaded DASH manifest is invalid (either some periods were removed illegally, or a manifest for a live event is stale), we will retry using 1 logic: - Retry loading with back-off up-to a limit. - Throw a DashManifestExpiredException() if we exceed retry limit. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=182770028
-
由 eguven 提交于
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=182754993
-
由 olly 提交于
Also disable use of dummy surface for devices that require the workaround. It's only useful in the case that we can use setOutputSurfaceWorkaround, so if it's disabled the dummy surface has no purpose (it actually makes things worse by consuming past the key-frame prior to the current position, which doesn't happen if you have no surface at all). Issue: #3724 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=182750068
-
由 eguven 提交于
This fixes a very specific case where the data read has non-cached gaps and a read-only CDS switches to read from upstream in a gap then the cached data is deleted. When the CDS reaches the end of the gap, it tries to open the next source. As there is no cached data, it tries to continue with the already opened upstream data source but as it reached end of the gap range, the code starts looping. Also fixes infinite lock which occurs when in the previous case CDS isn't readonly. It locks the content while filling the gap in the cache. At the end of the gap, as the following data is deleted it tries to lock the content for writing but the content is already locked by itself. The last fix is preventing removal of CachedContent entry from CachedContentIndex while associated key is locked. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=182595426
-
由 tonihei 提交于
Some tests in ExoPlayerTest issue commands to the player from the test thread while the player is actively playing media (playWhenReady=true). Due to the indeterminate time taken to enqueue the commands on the playback thread, they may arrive when the player already proceeded to another window or finished playback. To ensure the tests are always deterministic, this change pauses playback in the tests where this may happen before issuing the commands. Also, for tests where we need to wait for a new window before issuing the next command, a new action is added which allows to play until a specified position. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=182535096
-
由 olly 提交于
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=182534505
-
由 aquilescanta 提交于
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=182533415
-
由 olly 提交于
- Get handling of "stale" and "out of sync" manifests so they're right next to each other (to be merged) - Move startLoadingManifest to be next to the methods that schedule it, and actually start loading stuff. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=182530683
-
由 tonihei 提交于
As soon as the seek gets acknowledged by EPII, EPI returns the actual position from the playback info again which is set by EPII. Thus, EPII needs to update the position to reflect the changes expected by EPI. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=182515106
-
由 bachinger 提交于
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=182512582
-
由 olly 提交于
- In IDLE, the button will now call a preparer. This allows removal of the separate retry button from the demo app. - In ENDED, the button will seek back to the default position and play. - Behavior is made consistent with LeanbackPlayerAdapter. Issue: #3689 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=182506855
-
由 tonihei 提交于
When determining the next sample to load, the Mp4Extractor now takes into account how far one stream is reading ahead of the others. If one stream is reading ahead more than a threshold (default: 10 seconds), the extractor continues reading the other stream even though it needs to reload the source at a new position. GitHub:#3481 GitHub:#3214 GitHub:#3670 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=182504396
-
由 kqyang 提交于
Add SAMPLE-AES-CTR, which replaces SAMPLE-AES-CENC per latest spefication: https://storage.googleapis.com/wvdocs/Widevine_DRM_HLS.pdf. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=182407790
-