SDK / exoplayer

More info in: https://developer.android.com/about/versions/13/behavior-changes-13#granular-media-permissions

PiperOrigin-RevId: 506908079

This is more flexible for apps and more consitent with the Player API.

PiperOrigin-RevId: 506901645

PiperOrigin-RevId: 506900817

PiperOrigin-RevId: 506898392

* Overload added `(cause, errorCode, isVideo, isDecoder, details)`,
where `details` is a string of values to be added to the error message
of the `TransformationException`.
* Overload with `MediaFormat` and `mediaCodecName` moved to
`DefaultCodec`, because all usages of that overload were from
`DefaultCodec`, and this allows a simplified API because of internally
stored values.
* `mediaCodecName` removed from overload that takes a `Format`.
* Reordered `createForCodec` parameters.

PiperOrigin-RevId: 506895268

PiperOrigin-RevId: 506890459

PiperOrigin-RevId: 506886903

In encoding small and odd-numbered resolutions, like `316x61` ([this image](https://upload.wikimedia.org/wikipedia/commons/6/65/100winners.png)), the current fallback logic prefers a software encoder to hardware ones. The assumption was, the encoder factory applies the encoder size alignment and changes the resolution to `316x60` for SW encoders and `316x64` for HW ones. SW encoders is selected because the supported resolution 60 is closer to requested 61, than the hardware supported 64.

This change changes the default encoder selection process to only expose hardware encoders if there is any.

PiperOrigin-RevId: 506879983

With multi-asset, the sample pipelines can process more than one
MediaItem. The renaming makes it clear that the format passed to the
SamplePipeline constructors is the one corresponding to the first
MediaItem. Indeed, the first format is the one used to configure the
SamplePipelines.

PiperOrigin-RevId: 506879260

This avoids affecting ExoPlayer metrics with non-typical usage.

PiperOrigin-RevId: 506878231

PiperOrigin-RevId: 506874799

PiperOrigin-RevId: 506868341

PiperOrigin-RevId: 506863538

Set the correct output color on the debug SurfaceViewWrapper, so that SDR contents
can have an output transfer of either GAMMA_2_2 (Gamma 2.2) or SDR (SMPTE 170M).

This fixes an issue where in-app tone-mapping would output gamma 2.2, and the
SDR value incorrectly hardcoded here would lead to an error in the OpenGL, which
does not support SMPTE 170M.

PiperOrigin-RevId: 506684602

PiperOrigin-RevId: 506619637

Before this CL, the `renderedLastFrame` flag is not set if the last frame is released immediately (force render), or when it's dropped.

PiperOrigin-RevId: 506358626

With the current ExtTexMgr,

it can happen that

- `x` frames are registered, but haven't arrived yet
- flush
  - need to drop `x` frames when they arrive on SurfaceTexture
  - status is reset to 0 pending, 0 available, drop `x` when frames arrive
- register one frame
  - status is set to 1 pending, 0 available, drop `x` when frames arrive
- flush
  - now the number of frame to drop is reset to `pending - available = 1`
  - but it should be `x+1`

This CL solves the issue by reporting (by running the afterFlushTask) flush completes only after all the pending frames before calling flush are accounted for.

PiperOrigin-RevId: 506310671

The prior version (with the call to createEncodingException) could
never occur as select...SupportedMimeType already checks for HDR
editing support. This change ensures we throw before creating an
encoder, gives a better error code and allows future simplifications
around createForCodec (see child CL).

PiperOrigin-RevId: 506308290

PiperOrigin-RevId: 506304101

Flushing resets all the texture processors within the `FrameProcessor`. This
includes:

- At the back, the FinalMatrixTextureProcessorWrapper, and its MatrixTextureProcessor
- At the front, the ExternalTextureManager
- All the texture processors in between
- All the ChainingGlTextureProcessorListeners in between texture processors
- All the internal states in the aforementioned components

The flush process follows the order, from `GlEffectsFrameProcessor.flush()`

1. Flush the `FrameProcessingTaskExecutor`, so that after it returns, all tasks queued before calling `flush()` completes
2. Post to `FrameProcessingTaskExecutor`, to flush the `FinalMatrixTextureProcessorWrapper`
3. Flushing the `FinalMatrixTextureProcessorWrapper` will propagate flushing through, via the `ChainingGlTextureProcessorListener`

Startblock:
   has LGTM from christosts
   and then
   add reviewer andrewlewis
PiperOrigin-RevId: 506296469

The eotf is needed so that overlay (image) colors are correctly interpreted and mixed the linear video colors.

Also replaces the 100winners.png with "homemade" image file.

Added GlEffectsFrameProcessor test to justify that the color looks correct at the end of frame processing.

PiperOrigin-RevId: 506290309

Can be used to combine multiple media items into a single timeline window.

Issue: androidx/media#247
Issue: google/ExoPlayer#4868
PiperOrigin-RevId: 506283307

PiperOrigin-RevId: 506261584

For HLG input in transformer, FinalWrapper is configured to only output HLG to
encoder. But since DebugPreview is configured to take PQ for HDR content, the
color will not look correct.

This CL allows overriding the MatrixTP output transfer function, so
that FinalWrapper can output

- HLG to encoder
- PQ to debug preview

PiperOrigin-RevId: 506022840

Implementations outside media3 should be able to throw FrameProcessingException if they come across an error during configure().

PiperOrigin-RevId: 506020149

I missed this when fixing `positionInMs` for Dackka in https://github.com/google/ExoPlayer/commit/d2a3d8f6fabb6d22ac28a76379725d0915344cba

This time I manually verified that all the `@Override` methods have
parameter names that match [the docs](https://developer.android.com/reference/androidx/leanback/media/PlayerAdapter).

#minor-release

PiperOrigin-RevId: 506017063

And rename method `releaseOutputFrame` to `releaseProcessedFrameInternal` for consistency.

Removed misplaced comment.

PiperOrigin-RevId: 506005744

This overload is helpful to apps transcoding a MediaItem without edits.

PiperOrigin-RevId: 505987852

Transformer callbacks will take a Composition instead of a MediaItem.
Apps should be able to see what this Composition contains.

PiperOrigin-RevId: 505976561

PiperOrigin-RevId: 505960752

Add checks to GL tone-mapping pixel tests, to ensure the device's decoder, API
version, and OpenGL implementation support GL tone-mapping before attempting it.

These tests should be run on mobile harness, to detect per-device failures, and
so are moved to transforemr/mh. Per b/263395272, these tests should ultimately
be in an effect/mh directory.

PiperOrigin-RevId: 505749974

On some devices/builds it seems that the `SurfaceView` constructor tries to create a handler. Move instantiation to the main thread when getting the debug surface view so that handler creation succeeds.

PiperOrigin-RevId: 505745387

Make clearer the intermediate matrix property names.

PiperOrigin-RevId: 505732563

PiperOrigin-RevId: 505720834

PiperOrigin-RevId: 505671326

PiperOrigin-RevId: 505670386

ParcelFileDescriptor is quite specific and removing it allows to have
less overloads of startTransformation.

A follow-up CL will undeprecate the overload that takes a MediaItem.

PiperOrigin-RevId: 505670321

AudioProcessor-based speed changes are not supported with
offload, so we should use the AudioTrack-based speed changes
by default if the user requests a speed change.

This moves the decision of which speed change path is used
into the Configuration, so that it can change for each
AudioTrack in a playlist.

PiperOrigin-RevId: 505621911

Otherwise, it's not clear if it's the expected output.

Renaming-only change. No functional change intended.

PiperOrigin-RevId: 505103740

When seeking in fMP4, we try to extract as little samples as possible
by only starting at the preceding sync frame. This comparison should
use <= to allow sync frames at exactly the seek position.

Issue: google/ExoPlayer#10941

#minor-release

PiperOrigin-RevId: 505098172