* 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
*** Original commit ***
Rollback of 20282151b5
*** Original commit ***
Fix PlayerView touch handling
Overriding onTouchEvent was causing multiple issues, and
appears to be unnecessary. Removing the override fixes:
1. StyledPlayerView accessibility issue where "hide player
controls" actually toggled play/pause.
2. Delivery of events to a registered OnClick...
***
PiperOrigin-RevId: 434502423
*** Original commit ***
Don't call MediaDrm.setLogSessionId in FrameworkMediaDrm
This method throws an UnsupportedOperationException on some Android 12
devices.
***
PiperOrigin-RevId: 433708582
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
This fixes an exception thrown when parceling becasue the type can not be found
(expects the AdsPlaybackState to be Serializable). Transforming the map and the
ad playback states to a Bundle fixes the problem.
#minor-release
PiperOrigin-RevId: 433491993
When the start position of a MediaPeriodInfo is equal or higher than the duration,
we set the start position to `duration - 1` to end on the last frame. With server
side inserted ad streams, this has the effect that we actually need to seek back to
the last content frame after a post-roll.
This is desirable when actually ending on that frame but produces a BUFFERING event
when transitioning from an SSAI stream with a post-roll to the next media item in
the playlist. This change sets the start position to the duration when we are
clipping the last content period of an SSAI stream that is played in a playlist.
PiperOrigin-RevId: 433445680
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
*** Original commit ***
Fix PlayerView touch handling
Overriding onTouchEvent was causing multiple issues, and
appears to be unnecessary. Removing the override fixes:
1. StyledPlayerView accessibility issue where "hide player
controls" actually toggled play/pause.
2. Delivery of events to a registered OnClickListener when
useController is false.
3. Delivery of events to a registered OnLongClickListener
in all configurations.
4. Incorrectly treating a sequence of touch events that
exit the bounds of the vi...
***
PiperOrigin-RevId: 433262414
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
Overriding onTouchEvent was causing multiple issues, and
appears to be unnecessary. Removing the override fixes:
1. StyledPlayerView accessibility issue where "hide player
controls" actually toggled play/pause.
2. Delivery of events to a registered OnClickListener when
useController is false.
3. Delivery of events to a registered OnLongClickListener
in all configurations.
4. Incorrectly treating a sequence of touch events that
exit the bounds of the view before ACTION_UP as a click,
both for delivery to OnClickListener and for toggling
the controls.
Note: After this change, control visibility will not be
toggled if the application developer explicitly sets the
view to be non-clickable. I think that's probably working
as intended though. It seems correct that a non-clickable
view would not respond to clicks.
Issue: google/ExoPlayer#8627
Issue: google/ExoPlayer#9605
Issue: google/ExoPlayer#9861
PiperOrigin-RevId: 433016626
This change rewrites the UI module's track selection
components to depend on the Player API, allowing us to
finally remove the UI module's dependency on ExoPlayer
as a concrete player implementation.
PiperOrigin-RevId: 432989318
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 makes the reading period advance early as expected at the end of an ad
period. Before this change the reading position of the metadata renderer
prevented advancing the period until metadata arrived after the start position of
the following period. Only then the reading position of the metadata renderer
is updated and beyond the start position of the following period which is a
condition to advance the reading period.
Because transitioning to the next period is a virtual transition and the
SharedMediaPeriod keeps reading from the same underlying sample streams, the
metadata renderer can safely be ignored for this check.
#minor-release
PiperOrigin-RevId: 432646037
We will be migrating our track selection UI components to be
based on TracksInfo. We need DownloadHelper to expose TracksInfo
to make it compatible with such components.
PiperOrigin-RevId: 432474487
addTrackSelectionForSingleRenderer takes a list of legacy overrides,
which are then set on the supplied parameters one at a time to run
track selection. This allows multiple overrides for a single track
type to be applied in the download use case, despite it not being
possible to place such overrides directly into a single parameters.
For new style overrides, multiple overrides for the same track type
can be placed directly into a single parameters. Therefore we'll be
able to replace use of addTrackSelectionForSingleRenderer with use
of addTrackSelection, which is a much cleaner API. For this to work,
we need to make DownloadHelper apply multiple overrides in this case.
PiperOrigin-RevId: 432459834
This will allow for easier customisation of the additional tasks
performed by the test runner, such as calculating metrics like SSIM.
PiperOrigin-RevId: 432434850
These should have been removed as part of 1391b7c65d, since we no
longer officially support overriding the layout file for this class.
This class is known as StyledPlayerView in exoplayer2.
#minor-release
PiperOrigin-RevId: 432411322
This method is no longer needed since we added SubtitleConfiguration#id
in 59d98b9a4e.
Issue: google/ExoPlayer#10016
#minor-release
PiperOrigin-RevId: 432169262
DownloadHelper is in the ExoPlayer module, so there's no reason
why it can't use ExoPlayer specific track selections. That said,
we want our UI components to operate on generic
TrackSelectionParameters, and we want such UI components to be
useful for selecting tracks for download. To keep this interop,
it's necessary to have DownloadHelper accept generic
TrackSelectionParameters, or to require application code to
convert them. The first approach seems preferable!
PiperOrigin-RevId: 432158846
This constructor always does the wrong thing for non-adaptive groups
containing more than 1 track, because it'll incorrectly generate an
adaptive selection. Replace it with a constructor for specifying a
single track within the group instead.
PiperOrigin-RevId: 431673458
Only log GL exceptions in GlUtil if they aren't thrown. Otherwise,
it's up to the caller whether or not to log them to avoid logging them
twice.
PiperOrigin-RevId: 431657397
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
As evidenced by the somewhat awkward logic in PlayerControlView, the
previous design wasn't very friendly to expected usage. There will be
more usage when the track selection dialog components are migrated,
which would be similarly awkward without this change.
PiperOrigin-RevId: 431407675
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
*** Original commit ***
Rollback of 8d9c4f4774
*** Original commit ***
Rollback of 43b796b64d
*** Original commit ***
Rollback of 08c5b1cb0a
*** Original commit ***
PiperOrigin-RevId: 430905772
