Also updated DefaultVideoFrameProcessor to create GlShaderPrograms with the working ColorInfo rather than the output ColorInfo.
PiperOrigin-RevId: 721748002
Most of the values for the output `MediaItemInfo` will be retained from the `ExportResult`, so it's now passed to `onExportSuccess` and `onExportError` directly. For now, the duration of the ouput is recorded for metrics, and more values will be added in the following CLs.
PiperOrigin-RevId: 721324689
This is necessary for prewarming. With prewarming, in a sequence of 2
videos, the second renderer is enabled before the first one is disabled,
and decode-only frames should be skipped before the second renderer is
started. The problem is that the second renderer will forward frames to
a BufferingVideoSink before it is started, which will delay the frame
handling and therefore not skip the frame before the renderer is
started.
PiperOrigin-RevId: 721032049
Before the change, `SequenceAssetLoader#onTrackAdded` was being called twice, for audio and video. `ExportResult.ProcessedInput` took one format, which was the latest to be written. The change leads to capturing both, the audio and video formats of the input, and prevents the issue of a format overwriting the other.
PiperOrigin-RevId: 720487697
playback_sequencesOfVideos_effectsReceiveCorrectTimestamps is failing
for prewarming. The following is happening:
- For prewarming, there are 2 alternating video renderers per sequence.
- When the first MediaItem ends (for both sequences), signalEndOfInput
is not called on the InputVideoSink (which is expected).
- The DefaultVideoCompositor doesn't receive the end-of-input-source
signal (which is also expected).
- As a result, the DefaultVideoCompositor never outputs the last frame
because it waits for more input frames to be fed.
- The VideoGraph thus doesn't output the last frame either, and the
first video renderer never ends.
- This causes playback to get stuck.
This is similar to the problem of supporting multiple video sequences
with images and videos in CompositionPlayer.
PiperOrigin-RevId: 720106413
Previously, the input media item's duration was collected from `ProcessedInput.durationUs`. However, this value turned out to be the duration of the media item after clipping. Getting the duration of the input media item before clipping is tricky, so it will be dropped from Editing Metrics V1.
PiperOrigin-RevId: 719254077
The fix is to update `AudioGraphInputAudioSink.lastHandledPositionUs` when a buffer is handled, and end the `AudioGraphInputAudioSink` as the final audio sink plays out further than this position.
PiperOrigin-RevId: 718901825
This is pre work required to remove `Muxer.java` interface
from the muxer module.
`Mp4Muxer` and `FragmentedMp4Muxer` will no longer implement
the `Muxer` interface.
PiperOrigin-RevId: 716669531
The `DataSpace` contains the Color Standard, Range, and Transfer. These values were mapped as follows:
* Standard: From `@C.ColorSpace` to `@DataSpace.DataSpaceStandard`
* Range: From `@C.ColorRange` to `@DataSpace.DataSpaceRange`
* Transfer: From `@C.ColorTransfer` to `@DataSpace.DataSpaceTransfer`
PiperOrigin-RevId: 716157142
If a format is passed to `ExportResult.ProcessedInput`, the `containerMimeType` and `sampleMimeType` are extracted from the Format and passed inside the `MediaItemInfo` object.
PiperOrigin-RevId: 715840400
This is to prevent facing errors in apps using Transformer. It will be enabled again once the project is done and comprehensive tests are added.
PiperOrigin-RevId: 715435613
Some checks in SingleInputVideoGraph were causing CompositionPlayer to
throw for a single media item sequence when repeat mode was enabled. The
reason was that, in this case, no new input stream is registered to the
VideoFrameProcessor.
PiperOrigin-RevId: 715409509
Added the creation of `MediaItemInfo` for each MediaItem and passed the duration of the MediaItem to it. This is done for export operations that complete with success or with error.
PiperOrigin-RevId: 714056270
In some cases encoders include a sample rate in their AudioCapabilities but do not support encoding at that sample rate. This breaks the assumption used to write these tests, so disable them for now until the fallback logic is updated to handle this limitation.
PiperOrigin-RevId: 714055556
Added reporting 2 values from Transformer:
- `exporterName`: name of the package calling for export. Example: "androidx.media3.transformer".
- `muxerName`: name of the muxer used for the export operation. Example: "androidx.media3.muxer".
PiperOrigin-RevId: 714000672
When CompositionPlayer added repeat modes in d0afb96c40, it
changed the logic in SimpleBasePlayer to workaround the specific
scenario in CompositionPlayer that didn't seem to work correctly.
The workaround is not really generically applicable though. The
source of the original problem was that the position values of
all state objects were connected to the "live" source of the
current player so that the repetition case couldn't be detected
(the position before and after the seek looked the same). The
solution is to use the newly added LivePositionSuppliers and
disconnect them before seeking.
PiperOrigin-RevId: 713659638
The audio decoder is sometimes failing with error "previous call to
queue exceeded timeout - Codec reported err 0x80000000, actionCode 0,
while in state 6/STARTED". This is probably because the emulator is too
slow.
PiperOrigin-RevId: 713564117
If an error occurred in the player before the test was calling one of
the waitUntilSomething() methods, a timeout exception was thrown instead
of the actual error.
PiperOrigin-RevId: 713292292
If a playback exception was thrown before or during awaiting the
frameCountBeforeBlockLatch, a TimeoutException was thrown instead of the
playback exception, hiding the actual cause of the failing test.
PiperOrigin-RevId: 713279627
This method is already quite complex and I will need to add more
complexity, so split it into multiple smaller methods.
This CL is a refactoring. There are no functional changes.
PiperOrigin-RevId: 713266816
