- 20 Apr, 2021 5 commits
-
-
See go/media-apis-codebase-google3. PiperOrigin-RevId: 369425137
andrewlewis committed -
Oliver Woodman committed
-
PiperOrigin-RevId: 369425007
Oliver Woodman committed -
The original cl has been fixed by not implementing VideoListener but Player.Listener in StyledPlayerView. VideoFrameMetadataListener and CameraMotionListener are still part of the Player interface as a good way to break the UI dependency on them has not yet been finalised. PiperOrigin-RevId: 369417682
krocard committed -
PlayerView is not affected. PiperOrigin-RevId: 369401563
krocard committed
-
- 19 Apr, 2021 9 commits
-
-
PiperOrigin-RevId: 369315524
olly committed -
This change moves the responsibility of creating, configuring and starting the MediaCodec from the MediaCodecRender to the MediaCodecAdapter.Factory. This move allows ExoPlayer's client to decide how and when codecs are created and/or reused. To allow the move, this CL replaces MediaCodecRenderer.ConfigureCodec with MediaCodecRenderer.getCodecConfiguration PiperOrigin-RevId: 369273887
olly committed -
PiperOrigin-RevId: 369215083
Oliver Woodman committed -
This was likely an oversight when first importing #4930. PiperOrigin-RevId: 369199775
tonihei committed -
https://github.com/google/ExoPlayer/commit/cdebf6c68b0f76360d78114dcb47c58e63b354a7
*** Original commit *** Move VideoComponent in ExoPlayer VideoFrameMetadataListener and CameraMotionListener are still part of the Player interface as a good way to break the UI dependency on them has not yet been finalised. *** PiperOrigin-RevId: 369194309
ibaker committed -
* Prefer instanceof to getClass when implementing Object#equals. (see http://go/bugpattern/EqualsGetClass) This CL looks good? Just LGTM and Approve it! This CL doesn’t look good? This is what you can do: * Suggest a fix on the CL (go/how-to-suggest-fix). * Revert this CL, by replying "REVERT: <provide reason>" * File a bug under go/error-prone-bug for category ErrorProneFragileCode if the change looks generally problematic. * Revert this CL and not get a CL that cleans up these paths in the future by replying "BLOCKLIST: <provide reason>". This is not reversible! We recommend to opt out the respective paths in your CL Robot configuration instead: go/clrobot-opt-out. This CL was generated by CL Robot - a tool that cleans up code findings (go/clrobot). The affected code paths have been enabled for CL Robot in //depot/google3/java/com/google/android/libraries/exoplayer/METADATA which is reachable following include_presubmits from //depot/google3/third_party/java_src/android_libs/exoplayer/METADATA. Anything wrong with the signup? File a bug at go/clrobot-bug. #codehealth PiperOrigin-RevId: 369180513
olly committed -
VideoFrameMetadataListener and CameraMotionListener are still part of the Player interface as a good way to break the UI dependency on them has not yet been finalised. PiperOrigin-RevId: 368863829
krocard committed -
Other tests in this file already use `Executors.newSingleThreadExecutor` so do the same for the ones that currently use `mockExecutor`. PiperOrigin-RevId: 368859470
andrewlewis committed -
PiperOrigin-RevId: 368851903
kimvde committed
-
- 16 Apr, 2021 7 commits
-
-
PiperOrigin-RevId: 368822503
bachinger committed -
PiperOrigin-RevId: 368818853
olly committed -
Before this change: - SimpleExoPlayer.prepare(mediaSource) ended up calling ExoPlayerImpl.setMediaSourcesInternal() with startWindowIndex=0 and resetToDefaultPosition=false. - ExoPlayerImpl.prepare(mediaSource) ended up calling ExoPlayerImpl.setMediaSourcesInternal() with startWindowIndex=C.INDEX_UNSET and resetToDefaultPosition=true. This was functionaly equivalent but a bit confusing. #minor-release PiperOrigin-RevId: 368818143
kimvde committed -
Even when fixed to the US locale (and thus avoiding surprising behaviour in e.g. Turkish locale with "i" and "I") there are unexpected behaviours when upper and lower casing non-ASCII characters. For example it's sometimes not symmetric, e.g.: "ẞ".toLowerCase() -> "ß" "ß".toUpperCase() -> "SS" In all the ExoPlayer usages we are either dealing with known-ASCII strings (e.g. MIME types) or comparing against ASCII constant strings anyway, so it seems easier to just use Guava's ASCII-only class in these cases. Util.toUpperInvariant() is null-tolerant, while Ascii.toLowercase() is not. Most usages in this change are clearly non-null. The BandwidthMeter usages aren't annotated @Nullable, but the current code *would* work if countryCode was null in both cases. These methods will now throw NPE if they're passed null. PiperOrigin-RevId: 368816287
ibaker committed -
PiperOrigin-RevId: 368803206
Oliver Woodman committed -
PiperOrigin-RevId: 368789636
jaewan committed -
This is necessary to migrate apps which are using ExoPlayer.Builder.experimentalSetForegroundModeTimeoutMs from ExoPlayerImpl to SimpleExoPlayer. PiperOrigin-RevId: 368657557
kimvde committed
-
- 15 Apr, 2021 12 commits
-
-
* The Google Java Style Guide requires that each switch statement includes a default statement group, even if it contains no code. (This requirement is lifted for any switch statement that covers all values of an enum.) (see http://go/bugpattern/MissingDefault) This CL looks good? Just LGTM and Approve it! This CL doesn’t look good? This is what you can do: * Suggest a fix on the CL (go/how-to-suggest-fix). * Revert this CL, by replying "REVERT: <provide reason>" * File a bug under go/error-prone-bug for category ErrorProneStyle if the change looks generally problematic. * Revert this CL and not get a CL that cleans up these paths in the future by replying "BLOCKLIST: <provide reason>". This is not reversible! We recommend to opt out the respective paths in your CL Robot configuration instead: go/clrobot-opt-out. This CL was generated by CL Robot - a tool that cleans up code findings (go/clrobot). The affected code paths have been enabled for CL Robot in //depot/google3/java/com/google/android/libraries/exoplayer/METADATA which is reachable following include_presubmits from //depot/google3/third_party/java_src/android_libs/exoplayer/METADATA. Anything wrong with the signup? File a bug at go/clrobot-bug. #codehealth PiperOrigin-RevId: 368586454
olly committed -
PiperOrigin-RevId: 368585664
andrewlewis committed -
Discontinuity reasons may not be precisely obtained for remote player. 'Remote Player' means that playback is owned by another app or device and the same playback can be controller by other clients simultaneously. The MediaController is an example. If the remote playback doesn't provide discontinuity reason, then player cannot differentiate between automatic playback transition and seekTo() from another client. This CL tweaks the discontinuity reason definitions, so reasons can be obtained without remote playback's support. This doesn't effect the local Players, such as SimpleExoPlayer. PiperOrigin-RevId: 368579577
jaewan committed -
PiperOrigin-RevId: 368453894
jaewan committed -
PiperOrigin-RevId: 368448442
olly committed -
PiperOrigin-RevId: 368437660
krocard committed -
PiperOrigin-RevId: 368428647
krocard committed -
PiperOrigin-RevId: 368420961
olly committed -
Even when fixed to the US locale (and thus avoiding surprising behaviour in e.g. Turkish locale with "i" and "I") there are unexpected behaviours when upper and lower casing non-ASCII characters. For example it's sometimes not symmetric, e.g.: "ẞ".toLowerCase() -> "ß" "ß".toUpperCase() -> "SS" In all the ExoPlayer usages we are either dealing with known-ASCII strings (e.g. MIME types) or comparing against ASCII constant strings anyway, so it seems easier to just use Guava's ASCII-only class in these cases. This change also includes some null-twiddling, because Util.toLowerInvariant() is null tolerant, while Ascii.toLowerCase() is not. Most of the usages were already non-null, and it was easy enough to change the remaining ones to be so by simple reordering of statements. I'll make an equivalent change for Util.toUpperInvariant() next. PiperOrigin-RevId: 368419813
ibaker committed -
PiperOrigin-RevId: 368418142
krocard committed -
Some usage of += had to be changed to use .add because GString can be implitly converted to String and back, but it is not the case for List<GString> and List<String>. PiperOrigin-RevId: 368416727
krocard committed -
PiperOrigin-RevId: 368413660
krocard committed
-
- 14 Apr, 2021 3 commits
-
-
PiperOrigin-RevId: 368388742
andrewlewis committed -
PiperOrigin-RevId: 368383121
jaewan committed -
It provides a way to associate PlaybackState with the current media item. Startblock: <unknown commit> is submitted PiperOrigin-RevId: 368354775
gyumin committed
-
- 13 Apr, 2021 4 commits
-
-
Use unitless numbers for WebView line-height values See https://developer.mozilla.org/en-US/docs/Web/CSS/line-height#prefer_unitless_numbers_for_line-height_values
Denise LaFayette committed -
PiperOrigin-RevId: 368235728
bachinger committed -
PiperOrigin-RevId: 368226576
ibaker committed -
Previously, we had separate MSG_SET_SURFACE and MSG_SET_VIDEO_DECODER_OUTPUT_BUFFER_RENDERER messages for setting different types of supported output. Use of these constants to switch between outputs during use of a player was confusing because not all video renderers support both message types. To switch from VideoDecoderOutputBufferRenderer to a Surface, it was sufficient just to send MSG_SET_SURFACE, since all video renderers support this and clear any other output that might be set. Conversely, to switch in the opposite direction, just sending a MSG_SET_VIDEO_DECODER_OUTPUT_BUFFER_RENDERER was not sufficient, because not all video renderers handle this message to clear any previous output. Hence it was necessary to explicitly clear a previously set surface using a separate MSG_SET_SURFACE message. Passing two messages to switch the output may prevent renderers from implementing the output switch efficiently. This change passes all outputs using a single message type, and requires that all renderers treat unsupported outputs as though null were passed (i.e., they clear any existing output). There are some other miscellaneous improvements: 1. Non-surface outputs are now passed to onRenderedFirstFrame. This fixes a bug in SimpleExoPlayer's onRenderedFirstFrame, where previously it could not correctly equality check the output corresponding to the event to its current output in the VideoDecoderOutputBufferRenderer case. 2. Fix SimpleExoPlayer to report surface size changes for the VideoDecoderOutputBufferRenderer case. Even though the surface is rendered to indirectly in this case, we can still query (and listen to changes to) the surface's size. PiperOrigin-RevId: 368215850
olly committed
-