- 25 1月, 2018 1 次提交
-
-
由 andrewlewis 提交于
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=183065262
-
- 24 1月, 2018 39 次提交
-
-
由 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
-
由 olly 提交于
It seems good to have EventLogger available from the library. In particular because when app developers use it and then submit bug reports, it makes it much easier to work out what happened. It will also allow EventLogger to be used across our (now multiple) demo apps. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=182389407
-
由 tonihei 提交于
This gets rid of the manual tracking of this queue with reading, playing, and loading period holders. Still keeping these names for queue access methods. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=182378944
-
由 olly 提交于
Also sanitize naming (PlayerView/PlayerControlView). ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=182364487
-
由 aquilescanta 提交于
Issue:#3622 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=182363243
-
由 olly 提交于
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=182261649
-
由 aquilescanta 提交于
This was broken by [] ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=182206548
-
由 aquilescanta 提交于
Issue:#3632 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=182202289
-
由 olly 提交于
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=182183184
-
由 aquilescanta 提交于
This solves the problem of having dense tracks' ids change. For example, if the available variants offer both HEVC and AVC video tracks, all video samples will map to the same sample queue even if IDs don't match. Issue:#3653 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=182070486
-
由 aquilescanta 提交于
Issue:#3653 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=182064250
-
由 olly 提交于
This avoids issues that can arise due to slight discrepancies between chunk start times (obtained from the manifest of segment index) and the timestamps of the samples contained within those chunks. Issue: #2882 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=182054959
-
由 eguven 提交于
This is a Scheduler implementation which uses Firebase JobDispatcher. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=182051350
-