The factory method is replaced by a public constructor and
configure() method which configures the input/output surfaces
and handles the OpenGL setup.
This is a prerequisite for removing the responsibility of the
caller to configureSizes() before creating the chain in a follow-up.
PiperOrigin-RevId: 437028882
This allows us to bypass many device-specific issues, that only occur when
decoding directly to an encoder surface, without OpenGL. This also allows us
to maintain fewer code branches, which require additional testing to verify
correctness.
PiperOrigin-RevId: 437003138
Allow apps to modify how frames are presented, via modifying resolution.
A follow-up CL will provide aspect ratio, cropping, etc.
PiperOrigin-RevId: 436963312
The FrameProcessorChain manages a List<GlFrameProcessor>.
FrameProcessorChainDataProcessingTest now tests chaining ScaleToFit-
and AdvancedFrameProcessors.
PiperOrigin-RevId: 436468037
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
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
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
TransformerTest sounds like a unit test for Transformer but these
tests test behaviour that involves multiple stages of the pipeline.
PiperOrigin-RevId: 425378369
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
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
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
Exceptions thrown by MediaMuxer are converted MuxerExceptions
and later to TransformationExceptions with ERROR_CODE_MUXING_FAILED.
PiperOrigin-RevId: 421033721
* 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
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
Follow-up to a comment on 6f0f7dd1be: Buffers that are useful to pass
to the sample/passthrough pipeline should either contain data or the
end of input flag. Otherwise, passing these buffers along is unnecessary
and may even cause the decoder to allocate a new input buffer which is
wasteful.
PiperOrigin-RevId: 411060709
This mime type is technically for the Muxer, and determines
the container used. In the context of the transformer, this can
be thought of more as a container mime type, to avoid confusion
with the video mime type and audio mime type.
Deprecates setOutputMimeType().
PiperOrigin-RevId: 410530707
If the number of samples changes, the sizes will help us to verify whether they are just split differently or extra data was added.
PiperOrigin-RevId: 407346280
This introduces a new option `setAudioMimeType` in `TranscodingTransformer.Builder` and a corresponding check whether the selected type is supported. This check is done using `supportsSampleMimeType` which is now part of the `Muxer.Factory` and `MuxerWrapper` rather than `Muxer`.
A new field `audioMimeType` is added to `Transformation` and the `TransformerAudioRenderer` uses this instead of the input MIME type if requested.
PiperOrigin-RevId: 405367817
This is achieved by only triggering one message at a time. After
triggering a message we send another to ourselves to know when the
following message can be triggered.
Other required changes:
- The messages need to be sorted correctly (by time and creation order)
- To prevent deadlocks when one thread is waiting for another,
we need to add new method to Clock to indicate that the current
thread is about to wait. This then allows us to trigger messages
from other threads in FakeClock.
- AnalyticsCollectorTest needed some adjustments:
- onTimelineChanged now deterministically arrives after the initial
timline is already known, so some of the period information changes
from window only to full period info.
- The playlistOperations test suffers from a bug that the first frame
is rendered too early and that's why we now get additional events.
PiperOrigin-RevId: 353877832
