The FrameProcessorChain manages a List<GlFrameProcessor>.
FrameProcessorChainDataProcessingTest now tests chaining ScaleToFit-
and AdvancedFrameProcessors.
PiperOrigin-RevId: 436468037
This currently causes the test to fail on Pixel 6 Pro running a recent S build
SQ1D.220205.004.
There is no need to test audio transcoding while we are measuring video
quality.
PiperOrigin-RevId: 435635314
ExternalCopyFrameProcessor's output dimensions match the input
size not the output size. So the intermediate texture size
should match the input size.
Also rename configureOutputDimensions to configureOutputSize.
PiperOrigin-RevId: 435058789
Use android.util.Size, whose naming is much easier to understand than Pair<Integer, Integer>, in both FrameProcessor and EncoderUtil.
PiperOrigin-RevId: 434813986
* Move auto-adjustments for transformation matrices from the
VideoTranscodingSamplePipeline constructor to the new
ScaleToFitFrameProcessor.
* Add GlFrameProcessor#getOutputDimensions() to allow for GlFrameProcessors with
different input and output dimensions. This is a prerequisite for
Presentation.
* Tested with unit tests (and manually just in case).
* A follow up CL will implement change the FrameProcessor input to be scale and
rotate values as requested by the user. This was kept out of this CL to
reduce CL review size. Presentation will also be implemented in a follow up
CL.
PiperOrigin-RevId: 434774854
As pointed out in a previous review, createFallbackTransformationRequest
can be a bit confusing to parse.
Added javadocs and renamed parameters appropriately, to make it slightly
more easy to understand.
PiperOrigin-RevId: 434733313
The variable marks the coordinates used to sample from a texture, so hopefully
this makes the naming a bit more descriptive.
This renames vTexCoords and aTexCoords. No functional changes intended.
PiperOrigin-RevId: 433499934
If an OpenGL call blocks because the encoder's input surface is full,
this will now block the background thread while the main thread can
continue querying encoder output and free up encoder capacity until
it accepts more input unblocking the background thread.
PiperOrigin-RevId: 433283287
With the new version, we try the following before fixing resolution:
- Fix size alignment
- Try 3/4 the width and height
- Try 2/3 the width and height
- Try 1/2 the width and height
Also: align the resolution ends in 1 or 9 to 0.
PiperOrigin-RevId: 433206358
Previously, we've used getSupportedHeights/Widths() to find the supported
resolution. However, the height/width can be over-reported when using these
APIs. For example, getSupportedWidths and getSupportedHeights can both return
3840, but the supported height when using 3840 as width is only 2160.
PiperOrigin-RevId: 432926192
This will allow for easier customisation of the additional tasks
performed by the test runner, such as calculating metrics like SSIM.
PiperOrigin-RevId: 432434850
This test tests the same cases as the FrameEditorDataProcessingTest
as currently the main FrameEditor functionality is to apply a
transformation matrix using a TransformationFrameProcessor.
PiperOrigin-RevId: 431642066
We use SSIM to measure the transcoding quality between. SSIM is a widely used
tool that compares the luma channel between two images, and generates a score
from 0 to 1 that indicates "how similar" the two images are.
In `SsimHelper`, we decode the two videos, extract matching frames and
calculates the mean SSIM (SSIM averaged all matching frames) for both videos.
Matching frames are referred to as "comparisonFrame" in the CL, which is
selected based on the frame number and a user-set comparison interval.
For instance, if the interval is 7, then every seventh frames are compared.
We use MediaCodec/MediaExtractor to decode the video, and use ImageReader to
extract the decoded frame.
The SSIM calculation logic is a inspired by and modified from the CTS
[MSSIMMatcher](https://cs.android.com/android/platform/superproject/+/master:cts/tests/tests/uirendering/src/android/uirendering/cts/bitmapcomparers/MSSIMComparer.java;l=1?q=mssimcom)
that has some errors and extra features we don't need (like handling RGB
images).
Adds TranscodeQualityTest to ensure high quality transcoding.
PiperOrigin-RevId: 430951206
We need to access internal state to work around resources not being released on
old API versions. Add a reference to the bug about this and suppress the lint
warning.
#minor-release
PiperOrigin-RevId: 430190794
All (later customizable) GlFrameProcessors after the
ExternalCopyFrameProcessor receive their input from a normal OpenGL
texture not an external texture, so they won't need to worry about
the textureTransformMatrix.
PiperOrigin-RevId: 430165652
There are two major blockers to this test:
- H265 muxing is not available for API<24, so setting video mimeType to H265
will fail on those devices.
- AMR audio encoding is buggy on some device and it's not a widely used format.
The solution: use a video that is encoded with AVC/MP3, to ensure transcoding
to AVC/AAC.
PiperOrigin-RevId: 429648598
Re-enable tests that have no muxer support for timestamps going backwards.
Tests running on the B-frame sample will be added in a future commit.
#mse-bug-week
PiperOrigin-RevId: 429599177
We use the `createForCodec` method that does not take a `MediaFormat` during
transformation, the error message always includes "no configured MediaFormat",
which is false.
PiperOrigin-RevId: 429553573
Calling `MediaMuxer.writeSampleData` can block indefinitely on old API versions. It is better not to call this method to fail quickly with an exception rather than getting stuck.
Based on on-device testing media muxer doesn't generally handle out of order samples before API 25. There are a small number of devices where this does succeed but it seems preferable to turn this off everywhere to keep the code simple and have consistent behavior. Once we switch to in-app muxing this limitation will no longer apply.
#mse-bug-week
PiperOrigin-RevId: 429070255
Tested:
Verified that the additional information is available through
instrumentation tests, as well as via manual testing.
#mse-bug-week
PiperOrigin-RevId: 429038695
- The resources were released twice before, which is not necessary since
the MSG_RELEASE message is already in the internal player queue.
- The demo app was failing because the stop watch was stopped in
onTransformationError after being reset.
#minor-release
#mse-bug-week
PiperOrigin-RevId: 428794426
The GlFrameProcessor handles everything related to the GLSL program,
the FrameEditor manages the GL context and the data flow including
the input SurfaceTexture and output EGLSurface.
This will be split up further in follow-up CLs so that
GlFrameProcessors can be chained. At this CL, there are no
functional changes intended.
PiperOrigin-RevId: 428779179
We have seen devices running on API21/23 fail transcoding because of setting
encoding profile/level.
Some devices (ale-123/nexus 7) on API21 returns ENOSYS (Function not
implemented) when being configured with a profile setting. (although API21
introduced the capability of setting encoding profile)
Some devices (nexus 5) on API23 fails configuration with a specific parameter
set, despite advertising support for it.
Not setting the baseline profile has no effect on encoding, because when not
set, the encoding will pick a suitable profile to use. Since baseline is
the lowest possible profile, the auto-picked value can't be worse than
baseline.
Ref: b/218696352
PiperOrigin-RevId: 427792124
On some Android devices, the return value of
```
MediaCodecInfo.getCapabilitiesForType(mimeType).profileLevels
```
contains one entry for each encoding profile, like <profile, maxSupportedLevel>
but on some other devices, there are multiple entries for the same profile,
like <HIGH_PROFILE, LEVEL1>, <HIGH_PROFILE, LEVEL2>, <HIGH_PROFILE, LEVEL3>,
where we need to iterate through all the entries and find the max.
PiperOrigin-RevId: 427727030
On some old devices, the encoding level needs to be set with the encoding
profile, but not on newer devices.
The profile/level override is applied by following
https://developer.android.com/guide/topics/media/sharing-video
PiperOrigin-RevId: 427008536
This is a breaking change if the annotation itself is in use in Kotlin
code. It's judged that the IntDefs in this commit are unlikely to be
referred to often in Kotlin code. This is because they're either:
- Related to esoteric parts of the library, or
- In a common part of the library but only returned from methods (and
never passed to callback methods).
A follow-up change will fix the positions of existing usages to match
this new config.
#minor-release
PiperOrigin-RevId: 426410237
Fallback is only disabled for robolectric and instrumentation tests.
For MH tests, fallback is not disabled, as it may be needed due to
the broad range of devices available.
PiperOrigin-RevId: 426403167
Reason for not rolling back the rollback d68b790077: file name changed and
file content moved, the automated tool is unable to correctly apply the change.
Apply suggested AVC profile depending on the API version.
Use `AVCProfileHigh` only when there's encoder support.
PiperOrigin-RevId: 426363780
This change makes GlUtil.Program an outer class named GlProgram,
and also moves private static helpers as well as the inner classes
Attribute and Uniform which were only used by GlUtil.Program to
GlProgram. Other static utility methods remain in GlUtil.
No functional changes intended.
PiperOrigin-RevId: 426119299
The longer list of targets is only necessary for backwards
compatibility with existing Kotlin code that will stop compiling
if the position of the annotation becomes 'wrong' by marking it only
TYPE_USE. Since none of these IntDefs have been released (except in
media3 alpha1) we don't need to maintain this compatibility.
Also add a comment to all the places that *do* need the longer list of
targets, in order to explain why it's there and discourage copy-pasting
when defining new IntDefs in future.
Also fix some single-element arrays to remove the array notation.
#minor-release
PiperOrigin-RevId: 426108537
- The MIME type should ideally default to HEVC if there is an encoder for it.
- Next, check if AVC is supported.
- If there is no encoder for AVC, then we should pick an encoder in the list of
existing encoders instead of abandoning the transformation.
PiperOrigin-RevId: 425900638
Tested by confirming transformations still work and write to a output file in a
scoped-storage directory on a:
* Nexus 6P API 23 emulator
* Google Pixel 4 API 31 physical device
PiperOrigin-RevId: 425644266
- 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
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
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
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
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
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
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 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 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
Simplifying and clarifying variables, and adding comments.
Tested by confirming demo-gl and demo-transformer both
correctly display videos
PiperOrigin-RevId: 421792079
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
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 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
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
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
Move static factories into a separate class and make it implement an interface
that will let tests customize encoder/decoder creation.
PiperOrigin-RevId: 417610825
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
