- Add a checkbox in the demo app to enable experimental HDR editing.
- Add an `experimental_` method to `TransformationRequest` to enable HDR editing.
- Add fragment/vertex shaders for the experimental HDR pipeline. The main difference compared to the existing shaders is that we sample from the decoder in YUV rather than RGB (because the YUV -> RGB conversion in the graphics driver is not precisely defined, so we need to do this to get consistent results), which requires the use of ES 3, and then do a crude YUV -> RGB conversion in the shader (ignoring the input color primaries for now).
- When HDR editing is enabled, we force using `FrameEditor` (no passthrough) to avoid the need to select another edit operation, and use the new shaders. The `EGLContext` and `EGLSurface` also need to be set up differently for this path.
PiperOrigin-RevId: 425570639
TransformerTest sounds like a unit test for Transformer but these
tests test behaviour that involves multiple stages of the pipeline.
PiperOrigin-RevId: 425378369
Add a constructor that takes a DrmSessionManagerProvider.
This allows R8 to strip the default implementation.
#minor-release
PiperOrigin-RevId: 425330083
Some phone with limited memory can't allocate bigger
shared memory buffers.
This might or might not be related to Binder's 1M
transaction limit.
Tested on Pixel 4 by setting the minimum buffer size to
1h.
https://github.com/google/ExoPlayer/issues/9712
#minor-release
PiperOrigin-RevId: 425324536
If
a) the end of stream buffer arrives with a frame rather than an
empty buffer or
b) processDataV29() renders several decoder output buffers to the
FrameEditor's input Surface immediately before encountering the
EOS flag
these frames were previously stuck in the FrameEditor's input Surface
and never fed to the encoder.
PiperOrigin-RevId: 424898820
This test tests that all frames are processed when transcoding
video to a different sample MIME type (and that the transformation
completes successfully).
PiperOrigin-RevId: 424896014
Enforcing the correct thread usage has been enabled since 2.13.0.
Opting-out of this enforement is dangerous as it can hide very hard
to debug bugs.
PiperOrigin-RevId: 424815808
If muxerWrapper.release() was throwing an exception, the progress state
was not updated and getProgress could throw an exception.
#minor-release
PiperOrigin-RevId: 424696783
When the decoder output buffer was partially read, a call to
Codec.getOutputBuffer() was returning the same buffer, but with the
position reset to 0. The reason was that, in
Codec.maybeDequeueAndSetOutputBuffer(), mediaCodec.getOutputBuffer()
was called with the same buffer index (L350 in old rev), even though
there was already a buffer available (outputBufferIndex >=0). This
change avoids calling mediaCodec.getOutputBuffer() if the previous
buffer has not been released.
#minor-release
PiperOrigin-RevId: 424612197
If the encoder picks a fallback resolution the video pipeline needs
to take this into account when configuring the frameEditor and when
setting up the fallback TransformationRequest that's passed to the
fallbackListener.
PiperOrigin-RevId: 424611290
Move the code in its own class as DefaultAudioTrack
is getting very big. It also help for testability.
The new class is easily configurable and highly tested.
Manual test was used to catch any regression.
https://github.com/google/ExoPlayer/issues/8891
PiperOrigin-RevId: 424602011
AnalyticsCollector can't be null when passed into ExoPlayerImplInternal,
so there is no need to pass it around as nullable.
PiperOrigin-RevId: 424594031
Two of the sessions are finished at the same time in the test
and the order of the corresponding callbacks depends on the randomly
generated session string and the order these strings are stored in a
HashSet.
Update test to assert both callbacks are called and they contain the
right arguments, but don't assert on the order of these two callbacks.
PiperOrigin-RevId: 424548819
Ad playback shouldn't be affected by manual speed adjustments set
by the user. This change enforces unit speed for ad playback.
Issue: google/ExoPlayer#9018
PiperOrigin-RevId: 424546258
This only affects playbacks using the
experimentalUseProgressiveMediaSourceForSubtitles method.
Also update the SingleSampleMediaSource instantiation to be more
similar, to try and highlight differences like this in future.
PiperOrigin-RevId: 424545980
In some cases we need to update the PlaybackParameters at period
boundaries, for example when switching from live to VOD and live
playback speed adjustment was still active at the point of switching.
Currently, we send the update when the playing MediaPeriod changes in
EPII, which is slightly too late because the new speed gets only applied
after the entire existing AudioTrack buffer has been played out.
We can time the update slightly better by updating the values at the
point where we change the reading period. This makes the update slightly
too early because it also applies to all samples currently in the
decoder. But generally, this is a lot better because the time spent
in the decoder is likely to be considerably lower than the duration of
the AudioTrack buffer.
Note that this change isn't perfectly aligning to the period boundary,
but reduces the number of samples with the wrong speed to a minimum.
If we are getting around to add additional code that allows updating
the speed at exactly the boundary, it also needs to be triggered from
the reading period update, so the new code location is also helpful in
the future.
Issue: google/ExoPlayer#9018
PiperOrigin-RevId: 424540551
Issue: google/ExoPlayer#9775
We got a few issues for this on GH already. Some RTSP servers do not provide
track timing in PLAY responses, or the timings are invalid.
Missing timing means the RTSP stream is not seekable. Added method to
1. Update the timeline that seek is not possible
2. Report read discontinuity so that playback can start from the beginning.
PiperOrigin-RevId: 423281439
If the output sample MIME type is inferred from the input
but is not supported by the muxer, we fallback to transcoding
to a supported sample MIME type.
The audio and video renderers need to make sure not to select the PassthroughSamplePipeline for this case. Which sample MIME type
to choose is decided by the EncoderFactory.
PiperOrigin-RevId: 423272812
To avoid the `MediaPeriodQueue`to discard the reading period, we can set the next ad of an ad group early and then (possibly) only change it's duration once we receive the actual duration. This way we avoid a rebuffering as a result of the reading period being discarded.
The change also takes care to properly set ad break and their durations when we join the live stream at the moment when an ad is playing.
PiperOrigin-RevId: 423163467
We currently only end sessions on Timeline updates if the associated media
is no longer in the playlist. But we should also end all sessions that are
finished as a result of the timeline update (similar to how this is done for
discontinuities). This issue was introduced by 394ab7bcfd
PiperOrigin-RevId: 423075855
We currently don't check which session is causing a network transfer
(it could be a preloaded item in a playlist). To clearly associate
network transfer data with sessions, we need to keep track of
transferred bytes and transfer time per session.
PiperOrigin-RevId: 422867845
We may fall back to a different sample MIME type because
a) the sample MIME type inferred from the input is not supported
by the muxer or b) no encoders are available for the the requested
sample MIME type.
PiperOrigin-RevId: 422849036
With this change, the MediaCodecAudioRenderer configures the MediaCodec
to not downmix audio only if spatialization can be applied. This way,
decoders who are downmixing by default are left doing so when
spatialization cannot be applied. The renderer re-initializes the codec
when spatialization properties change mid-playback.
PiperOrigin-RevId: 422822952
TransformationRequest is otherwise immutable, so if we modify the
transformationMatrix in place (done before this cl) this may cause
confusing behaviour for apps when they reuse a TransformationRequest.
PiperOrigin-RevId: 422822916
Currently, we keep the values for dropped/played frames, audio underruns
and current formats from the last session, causing double reporting
of counters and wrong track change reasons for formats. All these
values should be reset when the active session is finished, so that the
new session can start from scratch.
PiperOrigin-RevId: 422798406
Currently, we always end the current session if onSessionFinished is
called. However, the finished session may not be the active one (for
example when discarding prebuffered items in a playlist). To make this
code more robust, we can save the active session id explicitly and only
end this session.
PiperOrigin-RevId: 422788542
After implementing fallback, it won't always be possible to
differentiate between muxer and encoder as the cause of an output
format not being supported.
PiperOrigin-RevId: 422780443
This change enables the ImaServerSideAdInsertionMediaSource for multi-period content. The global ad playback state is split into pieces for each period and the window and period durations are calculated accordingly in the ServerSideAdInsertionTimeline.
For multi-period live content (DASH), the ad playback state is not set with this change. This is deferred to a follow up CL. Splitting is very tricky. For each timeline update the windowStartTimeUs may vary for some milliseconds relative to the start of the period.positionInWindowUs. This requires to either introduce some fuzzy logic or to choose a different approach than for multi-period VOD. Because mistakes within the playback states of subsequent moving live windows produces crashes, it seems sensible to defer this for now and keep this change in a separate future CL (unblock further work, easy to rollback).
In this state, live DASH stream are working and the ad overlay is placed over the player correctly bu the SDK. However, ads are not reported by the position discontinuity event. Similarly, the player.isPlayingAd() does never returns true when a ad period is playing.
PiperOrigin-RevId: 422539770
This CL implements fixing the input format to the encoder spec. Fixed
parameters include:
- MIME type
- Profile & level
- Resolution
- frame rate, and
- bitrate
PiperOrigin-RevId: 422513738
The MediaMetricsListener currently just looks at the mime type and
doesn't use the inference based on the URI if no mime type is set.
Also change default type to OTHER to avoid classifying streams from
URLs without clear file extension as progressive.
PiperOrigin-RevId: 422373381
Instead of having types in flac inherit types in vorbis, make types in
vorbis inherit types in flac. This is a bit of a hack and somewhat
messy, but it retains backwards compatibility.
Collapse the two variations of `VorbisUtil.buildMetadata` into a single
method called `VorbisUtil.parseVorbisComments` that only takes a list
of vorbis strings, compared to previously where it would take strings
and picture frame instance. Any code that relied on the old signature
now either concatenates picture frames and vorbis comments or copies
vorbis comments into an existing metadata instance.
Simplify how the comment header is parsed and eliminate a few possible
bugs in the process, such as:
- Metadata being overwritten directly by the comments header.
- The packet being rewound to 0 if it cannot find a comment header,
which might result in the cursor being moved to a bad position.
In the old `flac` module, superclass the deprecated types under the
moved types in the `vorbis` module. This ensures backwards compat
with existing library users.
Adaptive video and audio selections will be limited to formats with
the same level of DecoderSupport and HardwareAccelatationSupport, unless
specifically allowed by new flags.
If different levels of decoder support are available, prefer primary
over fallback decoders and hardware-accelerated over software decoders
(in this order). For video, also prefer more efficient codecs, if both
are supported by hardware-accelerated primary decoders.
Issue: google/ExoPlayer#4835
Issue: google/ExoPlayer#9565
PiperOrigin-RevId: 422345048
This change moves the video track selection to the generic
selection method introcuced for audio and text. This ensures
we can apply the same criteria for fixed and adaptive video
track selections. Implicitly, this reorders the preferences
for adaptive tracks to give non-quality preferences (like
preferred MIME type or preferred role flags) a higher priority
than number of tracks in the selection.
Issue: google/ExoPlayer#9519
PiperOrigin-RevId: 422310902
This does currently only happen by chance in replaceStream (called from
enable) if the stream previosly played read until C.TIME_END_OF_SOURCE.
enable already makes all changes done in resetPosition (except resetting
the reading position), so it's less error-prone and makes the intention
clearer if the same code is called from both enable and resetPosition.
The effect of this bug was quite limited because the numerical value
of readingPositionUs was only relevant for periods with changing
durations and server-side inserted ads.
PiperOrigin-RevId: 422300690
The app will be notified about fallback using a callback on
Transformer.Listener. Fallback may be applied separately for
the audio and video options, so an intermediate internal
FallbackListener is needed to accumulate and merge the track-specific
changes to the TransformationRequest.
PiperOrigin-RevId: 421839991
We currently run (almost) the same code for all track types.
De-duplicate this by using a single method that takes functional
interfaces for track-type dependent logic.
This has the benefit that all track-type dependent logic is
contained within their subclasses and the generic logic doesn't
need to make any assumption about the eligibility of tracks for
selection or adaptation, and doesn't need to access Parameters.
Make this change for audio and text only for now. Video can
be updated in a subsequent change.
PiperOrigin-RevId: 421811411
Simplifying and clarifying variables, and adding comments.
Tested by confirming demo-gl and demo-transformer both
correctly display videos
PiperOrigin-RevId: 421792079
The existing wording would be correct if prefixed with
"Returns false if [...]", but it seems confusing to a document a boolean
method in terms the condition it returns false - so I reworded it in
terms of when it returns true.
#minor-release
PiperOrigin-RevId: 421682584
After this change exceptions throw by MediaCodec during
encoding/decoding will result in TransformationExceptions with
ERROR_CODE_ENCODING_FAILED/ERROR_CODE_DECODING_FAILED.
Before this change ERROR_CODE_FAILED_RUNTIME_CHECK was used.
PiperOrigin-RevId: 421560396
Expected images are taken on emulators, so a larger acceptable
difference from expected images must be accepted on physical devices.
PiperOrigin-RevId: 421543441
Live speed adjustment is used for all live playback at the moment,
but has no user visible effect if the media is not played with low
latency. To avoid unnecessary adjustment during playback without
benefit, this change restricts the live speed adjustment to cases
where either the user requested a speed value in the MediaItem or the
media specifically defined a low-latency stream.
Issue: google/ExoPlayer#9329
PiperOrigin-RevId: 421514283
This ensures we test the API level specific logic, in particular
around 5G-NSA detection.
Robolectric has a remaining bug that it doesn't support listening
to service state changes. Hence, we need to ignore some tests on
these API levels still until this is fixed.
PiperOrigin-RevId: 421505951
Codec and its factories can use MediaCodec directly as for API >= 21,
the SynchronousMediaCodecAdapter methods used in Codec just correspond
to a single MediaCodec call each so there is no reason to have another
wrapping layer.
PiperOrigin-RevId: 421041177
Exceptions thrown by MediaMuxer are converted MuxerExceptions
and later to TransformationExceptions with ERROR_CODE_MUXING_FAILED.
PiperOrigin-RevId: 421033721
The media codec renderers have fallback logic in getDecoderInfos
to assume that E-AC3 decoders can handle the 2D version of E-AC3-JOC and
that H264/H265 decoders can handle some base layer of Dolby Vision
content. Both fallbacks are useful if there is no decoder for the
enhanced Dolby formats.
Both fallbacks are not applied during track selection at the moment
because the separate MediaCodecInfo.isCodecSupported method verifies
that the mime type corresponding to format.codecs is the same as the
decoder mime type (which isn't true for the fallback case).
To fix the fallback logic, we can just completely remove this additional
check because it's not needed in the context of this method that is only
called after we already established that the decoder can handle the
format.sampleMimeType.
In addition, we need to map the Dolby Vision profiles to the equivalent
H264/H265 profile to make the codec profile comparison sensible again.
PiperOrigin-RevId: 420959104
SampleQueues may be released in the context of a finally block
after an out of memory error. Allocating in that scenario can
throw yet a new OutOfMemoryError. By safely releasing SampleQueue
memory, we increase the possibility of handling the error
gracefully.
PiperOrigin-RevId: 420859022
This method has been deprecated since 2.12.0 ([commit](d1bbd3507a)).
Also remove
DashMediaSource.Factory#setLivePresentationDelayMs(long, boolean), this
method has been deprecated since 2.13.0 ([commit](41b58d503a)).
PiperOrigin-RevId: 420719877
This class is already called StyledPlayerControlViewLayoutManager, it
seems unecessary to repeate the 'styled' word again in this context.
PiperOrigin-RevId: 420711161
These were missed in 46ab94bd41
These references will be re-written to PlayerView when exporting to
exoplayer2, so this commit results in some small reformatting changes.
Also fix a reference to LegacyPlayerControlView that should be
StyledPlayerControlView.
PiperOrigin-RevId: 420707706
The draw method was disabling vertex attrib arrays but not re-enabling them. Remove the call to disable the vertex attrib arrays so that then remain enabled after the program is created.
Manually verified by setting the surface type to spherical in the demo app and playing a spherical sample video.
Issue: google/ExoPlayer#9782
PiperOrigin-RevId: 420707503
Refactor the overall module to place the unified vorbis tags into a
single package called `vorbis`. Also re-intoduce the vorbis tags
in their original `flac` module, but deprecate them.
The encoder and sonic are now set up in the constructor rather
than in a configuration method called from processData(). This
is more similar to VideoSamplePipeline and reduces null checks.
PiperOrigin-RevId: 420260526
Only allowing TransformationExceptions to be created using the factory methods helps keeping error messages consistent. This is consistent with ExoPlaybackException.
PiperOrigin-RevId: 419841025
The UI component will be switched over to use them in a
subsequent commit, once the translations have been
imported.
Issue: google/ExoPlayer#9811
PiperOrigin-RevId: 419632617
Compensate for aspect ratio of input frames, so that they're applied on
rectangular frames instead of square normalized-device-coordinate frames.
This fixes distortion most visible when rotating any GL video 45°
(non-rectangular frames) or 90° (stretched frames)
Tested by rotating several landscape/portrait demo videos.
(Automated tests will follow in <unknown commit>)
PiperOrigin-RevId: 419619743
* Move checking that the output format is supported by the muxer
from supportsFormat (which deals with the input format) to
ensureConfigured.
* Add maps for the supported MIME types so that the muxer can
return what MIME types it supports rather than just check a
MIME type.
PiperOrigin-RevId: 419578165
The `main` role distinguishes a track from an `alternate`, but unlike
`SELECTION_FLAG_DEFAULT` it doesn't imply the track should be selected
unless user preferences state otherwise. e.g. in the case of a text
track, the player shouldn't enable subtitle rendering just because a
`main` text track is present in the manifest.
The `main`/`alternate` distinction is still available through
`Format.roleFlags` and the `ROLE_FLAG_MAIN` and `ROLE_FLAG_ALTERNATE`
values.
This behaviour was originally [added in 2.2.0](7f967f3057),
however at the time the `C.RoleFlags` IntDef did not exist. The IntDef
was [added in 2.10.0](a86a9137be).
PiperOrigin-RevId: 418937747
* @Override is not a TYPE_USE annotation, so should appear before any modifiers and after Javadocs. @CryptoType is a TYPE_USE annotation, so should appear after modifiers and directly before the type.
PiperOrigin-RevId: 418811744
This is better than silently dropping tracks as done previously. Later,
we will implement fallback to transcoding to a supported MIME type.
PiperOrigin-RevId: 418006258
This more closely matches the pattern we have for all implementations
except DefaultMediaSourceFactory (e.g. ProgressiveMediaSource.Factory)
and other factory interfaces like (Http)DataSource.Factory.
PiperOrigin-RevId: 417826803
Switch to using sentence-case naming convention but with one character prefixes for different types.
This is a no-op change.
PiperOrigin-RevId: 417791624
Some have been deprecated since 2.13.0
([commit](5b9fa7d7d9)):
* `setDrmSessionManager(DrmSessionManager)`
* `setDrmHttpDataSourceFactory(HttpDataSource.Factory)`
* `setDrmUserAgent(String)`
And the rest have been deprecated since 2.12.0
([commit](d1bbd3507a)):
* `setStreamKeys(List<String>)`
* `createMediaSource(Uri)`
PiperOrigin-RevId: 417622794
Move static factories into a separate class and make it implement an interface
that will let tests customize encoder/decoder creation.
PiperOrigin-RevId: 417610825
To support multi-period content we need to store AdPlaybackStates and
SharedMediaPeriod by the periodUid as a key. While after this no-op CL,
we still only support single-period content, storing these resources by
periodUid is the ground work for multi-period support being added in an
follow-up CL.
PiperOrigin-RevId: 416836445
Keep the old interface deprecated so any app code implementing it by
name (rather than with a lambda) will continue to work.
PiperOrigin-RevId: 416816566
Transformer uses ExoPlayer for reading input. Apps using Transformer
do not need to know this. So, PlaybackExceptions are converted to
TransformationExceptions with the same message, cause and error code.
The corresponding IO error codes are copied from PlaybackException.
PiperOrigin-RevId: 416793741
We check the fraction of the available duration we have already
buffered for live streams to see if we can increase the quality.
This fraction compares against the overall available media duration
at the time of the track selection, which by definition can't include
one of the availabe chunks (as this is the one we want to load next).
That means, for example, that for a reasonable live offset of 3 segments
we can at most reach a fraction of 0.66, which is less than our default
threshold of 0.75, meaning we can never switch up.
By subtracting one chunk duration from the available duration, we make
this comparison fair again and allow all live streams (regardless of
live offset) to reach up to 100% buffered data (which is above our
default value of 75%), so that they can increase the quality.
Issue: google/ExoPlayer#9784
PiperOrigin-RevId: 416791033
Before the introduction of the MediaCodecAdapter, users could get
access directly to the MediaCodec instance from
MediaCodecRenderer.getCodec() and then retrieve the codec metrics.
This change exposes MediaCodec.getMetrics() on the MediaCodecAdapter.
Issue: google/ExoPlayer#9766
#minor-release
PiperOrigin-RevId: 416343023
This is a no-op because all the <resource> elements from these XML
files are effectively concatenated together during building.
PiperOrigin-RevId: 416326534
*** Original commit ***
Rollback of 0aa23b08b1
*** Original commit ***
Add capability flags for hardware and decoder support
Issue: google/ExoPlayer#9565
***
***
PiperOrigin-RevId: 416285603
*** Original commit ***
Rollback of 27f905f571
*** Original commit ***
Don't sort decoders by format support in supportsFormat
This is a no-op change that updates supportsFormat to use the
decoder list before it's reordered by format support. Instead,
supportsFormat iterates through the decoders listed in their
original priority order as specified by the MediaCodecSelector.
The end result is identical.
This is n...
***
PiperOrigin-RevId: 416269130
*** Original commit ***
Don't sort decoders by format support in supportsFormat
This is a no-op change that updates supportsFormat to use the
decoder list before it's reordered by format support. Instead,
supportsFormat iterates through the decoders listed in their
original priority order as specified by the MediaCodecSelector.
The end result is identical.
This is necessary groundwork for a subsequent change that will
indicate in Capabilities whether the decoder that suppports the
format is the primary one as specifi
***
PiperOrigin-RevId: 416170612
This change adds a delegate class that loads and forwards calls
to a Spatializer with reflection, so that we can use the Spatializer
API before we update the compile SDK target to 32.
PiperOrigin-RevId: 416027289
The Robolectric implementation of HttpURLConnection forwards to the JRE
implementation [1], which behaves differently to the Android one
available on devices and emulators. For these tests to be a realistic
test of the HTTP stack used in real playbacks we can't use Robolectric.
Similar to df0e89c167
[1] https://github.com/robolectric/robolectric/issues/6769#issuecomment-943556156
PiperOrigin-RevId: 416013662
Opening the `DataSource` is one of the longer operations in the `Loader` sequence, as it requires a round trip to the origin server. This change allows all the potential `Loader` threads to perform this operation before one of them is forced to wait on shared TimestampAdjuster initialization.
Also, the initialization segment load will never produce media samples, so there is no need for it to wait for `TimestampAdjuster` initialization.
UnsupportedEglVersionException() is only used once, and seems a bit too
specific for Transformer. Also, it's possible for eglCreateContext to fail for
other reasons besides lack of support, so it wasn't always accurate when
thrown.
It is possible for devices not to support EGL version 2.0 though, per
https://source.android.com/devices/graphics/implement-opengl-es, which doesn't
specify the EGL version that must be supported.
PiperOrigin-RevId: 415489396
tl;dr:
In the previous transformer, the transcoding flow is
- If a the GL's input surface (from decoder) does not have data, wait 10ms
(DO_SOME_WORK)
- Else, make the decoder render **ONE** frame to the GL's input surface
- Wait at least 10ms, until the frame's texture is available
- Then process the texture
The process is quite slow, so in the new version, we do:
- If a the GL's input surface (from decoder) does not have data, wait 10ms
(DO_SOME_WORK) **same**
- Else, make the decoder render **as many frames** to the GL's input surface
- Process **as many** available textures in this DO_SOME_WORK cycle
PiperOrigin-RevId: 415474722
*** Original commit ***
Make audio track min buffer size configurable.
Move the code in its own class as DefaultAudioTrack
is getting very big. It also help for testability.
The new class is easily configurable and highly tested.
Manual test was used to catch any regression.
https://github.com/google/ExoPlayer/issues/8891
***
PiperOrigin-RevId: 415469179
The input rotation is used to rotate the video during decoding, the
video is rotated so that it is in landscape orientation before encoding
and a rotation is added to the output format where necessary so that
the output video has the same orientation as the input.
PiperOrigin-RevId: 415301328
Refactor GlUtil.java to be a bit more readable. Also, reorder, inline, and
rename a few things. Refactoring change only. No functional changes intended.
PiperOrigin-RevId: 415283874
For DASH manifests, we merge min/max live latency values from various
sources and they may not be consistent with each other. To ensure we
use a sensible configuration in all cases, we can add more correctness
checks:
1. Limit the min/max values to fall into the available live window.
2. Ensure that maxLatency >= minLatency in all cases.
Issue: google/ExoPlayer#9750
PiperOrigin-RevId: 415282938
Move the code in its own class as DefaultAudioTrack
is getting very big. It also help for testability.
The new class is easily configurable and highly tested.
Manual test was used to catch any regression.
https://github.com/google/ExoPlayer/issues/8891
PiperOrigin-RevId: 415268938
Being able to see the output of the GL pipeline is useful for debugging. For
example, when we previously saw flakiness it would have been useful to be able
to tell quickly whether the output looked wrong without needing to run a
transformation to the end then inspect the output file, and when working on
support for HDR editing it's useful to be able to do manual testing on devices
that don't support HDR encoding (but do support decoding/processing it with
GL).
Also change the progress indicator to be linear as this looks better in the
demo app when shown next to the debug preview.
PiperOrigin-RevId: 414999491
This is a no-op change that updates supportsFormat to use the
decoder list before it's reordered by format support. Instead,
supportsFormat iterates through the decoders listed in their
original priority order as specified by the MediaCodecSelector.
The end result is identical.
This is necessary groundwork for a subsequent change that will
indicate in Capabilities whether the decoder that suppports the
format is the primary one as specified by the MediaCodecSelector
(i.e., the one at index=0 in the lists that are now used).
Issue: google/ExoPlayer#9565
PiperOrigin-RevId: 414971986
The color set via textAppearance is overridden by any non-null
textColor set directly on the style. We always want the specific
properties the textAppearance specifies, so set them directly to
prevent them from being overridden.
#minor-release
Issue: google/ExoPlayer#9765
PiperOrigin-RevId: 414967143
Configure MediaCodec in API 32+ to always output 99 channels
so that we use the audio is spatialized, if the platform can apply
spatialization to it.
In a follow-up change, the output channel count will be set based on the
device's spatialization capabilities.
PiperOrigin-RevId: 414751543
`DefaultAudioSink` already has 3 telescoping
constructors and an other one would be have been
needed to add a buffer size tuning option.
PiperOrigin-RevId: 414703366
The existing code creates an imbalance between `inputBufferCount` and
`droppedBufferCount` by adding 'dropped source buffers' to
`droppedBufferCount` but not to `inputBufferCount`. This results in
assertion failures in `DashTestRunner`.
PiperOrigin-RevId: 414672175
It's been observed that some devices fail when releasing a secure codec
attached to a surface and immediately trying to create a new codec
(secure or insecure) attached to the same surface. This change catches
all exceptions thrown during codec creation, sleeps for a short time,
and then retries the codec creation. This is observed to fix the problem
(we believe this is because it allows enough time for some background
part of the previous codec release operation to complete).
This change should have no effect on the control flow when codec
creation succeeds first time. It will introduce a slight delay when
creating the preferred codec fails (while we sleep and retry), which
will either delay propagating a permanent error or attempting to
initialize a fallback decoder. We can't avoid the extra delay to
instantiating the fallback decoder because we can't know whether we
expect the second attempt to create the preferred decoder to succeed or
fail. The benefit to always retrying the preferred decoder creation
(fixing playback failures) outweighs the unfortunate additional delay
to instantiating fallback decoders.
Issue: google/ExoPlayer#8696
#minor-release
PiperOrigin-RevId: 414671743
The TrackSelection API returns two indexes, the index of the selected
track (`getSelectedIndex()`) and the index in the `TrackGroup`. The `HlsChunkSource`
and `HlsSampleStreamWrapper` should only work with the later.
Actually the `getSelectedIndex()`, current selected track index is really only useful on
the API to determine if there is a valid selection or not. The index is
really internal to `TrackSelection`
Also, add 144p as an acceptable output resolution, to allow for
a more obvious resolution difference when running the demo.
PiperOrigin-RevId: 414406664
The new field matches the platform's
AudioAttributes.getSpatializationBehavior() API added in Sv2. At the
moment, the platform API is called via reflection, until Sv2 is released
and the compile SDK target can be increased to 32.
PiperOrigin-RevId: 414406126
outputHeight is the actual output height while
transformation.outputHeight could be Format.NO_VALUE
causing the FrameEditor to be used more often than
necessary in the old version.
PiperOrigin-RevId: 414304251
When calling Android's Log class directly, there's a LongLogTag
lint check that detects tags over the 23 char limit, however it
cannot detect long log tags in ExoPlayer due to the way that we
log via our own Log class. This commit adds @Size annotations to
enforce the same rule.
PiperOrigin-RevId: 413976364
On the Sony Android TV device where this was originally reproducible on Android L, on Android N there is an E-AC3 decoder listed which handles the stream correctly. The workaround is harmless anyway but adding the API version restriction means it will be obvious it can be removed once we bump our min API to 24 or above in the future.
#minor-release
PiperOrigin-RevId: 413967443
Using chunkless preparation greatly improves start up time if the master
playlist declares CODECS for the renditions. Hence, we turn this on
by default as it benefits most well-defined HLS master playlists.
The only known reason why developers may want to turn this feature off is
when the renditions contain muxed closed-caption tracks that are not
declared in the master playlist. So this change also updates the documentation
and RELEASENOTES to point out this caveat.
PiperOrigin-RevId: 413950036
Increase timeout for dequeueing a frame from the codec to reduce flakiness. At a timeout of 2 seconds there was a 2/1000 flake rate and at 3 seconds 0/1000. Set the timeout to 5 seconds to give plenty of leeway.
PiperOrigin-RevId: 413946915
Hardware audio decoders aren't really a thing, particularly on older
devices. SOC vendors do sometimes provide their own software decoders
though. Hence we update the approximation to assume that audio
decoders on older devices are software.
PiperOrigin-RevId: 413757859
