forked from google/ExoPlayer
-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Impr/doris 1730 migrate exo 2.18.4 #77
Merged
guoen21
merged 2,085 commits into
release-v2-doris
from
impr/DORIS-1730-migrate-exo-2.18.4
Mar 21, 2023
Merged
Impr/doris 1730 migrate exo 2.18.4 #77
guoen21
merged 2,085 commits into
release-v2-doris
from
impr/DORIS-1730-migrate-exo-2.18.4
Mar 21, 2023
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* Add `setOutputStreamOffsetUs(long)` method in `AudioSink`. * Add private methods `setOutputStreamOffsetUs(long)` method in `MediaCodecRenderer` and `DecoderAudioRenderer`. * Add protected method `onOutputStreamOffsetUs(long)` method in `MediaCodecRenderer`, in which: * `MediaCodecRenderer` itself will be no-op for this method. * `MediaCodecAudioRenderer` will propagate this value to its `audioSink`. * Add logics in `DecoderAudioRenderer` to calculate `outputStreamOffsetUs`. PiperOrigin-RevId: 479265429 (cherry picked from commit 4c73241)
This mode is supported by using `C.TIME_UNSET` (which is a negative value). The new logic decouples the value of `C.TIME_UNSET` and the frame dropping behaviour. PiperOrigin-RevId: 479368880 (cherry picked from commit ccab9fb)
PiperOrigin-RevId: 479569806 (cherry picked from commit 7c68b8d)
Also, update tests to allow AnyOf error codes, and no longer check exception messages, which caused quite a bit of churn. PiperOrigin-RevId: 479570861 (cherry picked from commit faa796d)
PiperOrigin-RevId: 479579252 (cherry picked from commit a6b9772)
Currently, a frame is dropped if it's requested release time is in the past. This mode was added to support previewing. However, in normal ExoPlayer playback, slightly late frames (<30ms late) are also rendered. On MediaCodec side, this means calling `releaseOutputBuffer` with a release time in the past. PiperOrigin-RevId: 479615291 (cherry picked from commit 2188685)
If the sample type is Dolby Vision and the display does not support Dolby Vision, then the capabilities DecoderSupport flag is set to DECODER_SUPPORT_FALLBACK_MIMETYPE. This denotes that the renderer will use a decoder for a fallback mimetype if possible. This alters track selection as tracks with DecoderSupport DECODER_SUPPORT_PRIMARY are preferred. UnitTests included -DefaultTrackSelector test that checks track selection reordering with DECODER_SUPPORT_FALLBACK_MIMETYPE -MediaCodecVideoRenderer test that checks setting of DecoderSupport flag based on Display's Dolby Vision support Issue: google#8944 PiperOrigin-RevId: 480040876 (cherry picked from commit a366590)
We currently use the literal -1 (=NO_VALUE) when adding up the total. Tracks without known bitrate can be ignored in the calculation, but we should use an explicit value of 0. #minor-release Issue: google#10664 PiperOrigin-RevId: 480048126 (cherry picked from commit af19e0e)
PiperOrigin-RevId: 480349627 (cherry picked from commit 225d0dc)
Before, slider values were read as `floor()`'ed `longValue()`s, so that trimming to intervals less than one second would be interpreted as a request for a zero- duration trim. Also, rename `radiusRange` references here to `trimRange`, since this is not a radius range. PiperOrigin-RevId: 480401556 (cherry picked from commit 6c59f9e)
Player controls are somewhat distracting when showing the difference between the input and output video, as they obscure and darken the video players. PiperOrigin-RevId: 480597804 (cherry picked from commit 91a61ce)
Most demo videos aren't very long, and the default demo video is only 10 seconds. Shorten the maximum trim duration to 10 seconds, to demonstrate transformer functionality more easily, and allow this to be used more easily when trimming short sections of a longer video (ex. to make test clips) PiperOrigin-RevId: 480602037 (cherry picked from commit 3142a21)
When debugging and fixing Issue: google#10666 I wanted to write a regression test, but needed to add a test first... This is just a small bit of coverage to start with. It checks the field/channel filtering works correctly, but doesn't check any styling info. It also doesn't test 'pop on' subtitles (i.e. when the subtitle isn't shown until a 'end of subtitle' signal is received). PiperOrigin-RevId: 480644568 (cherry picked from commit 6052212)
- This method is redundant with getSupportedSampleMimeTypes(). - This is to prepare the Muxer class to become public. PiperOrigin-RevId: 480840902 (cherry picked from commit 8962f5a)
PiperOrigin-RevId: 480847967 (cherry picked from commit 446c994)
Adds root extras and metadata extras to MockMediaLibraryService and MockMediaBrowserCompatService and completed test cases for asserting interoperability with a media1 or Media3 browser. PiperOrigin-RevId: 480854842 (cherry picked from commit f95406e)
We already have logic to end all session except the current one if the current one doesn't have a MediaPeriodId yet. This is assuming that this only happens after a seek on the app side where the player doesn't have detailled knowledge about the MediaPeriodIds yet. Currently this logic isn't triggered if the window we are coming from doesn't have its MediaPeriodId either as we run into another check that keeps sessions around until we have a valid windowSequenceNumber. Swapping both conditions fixes this case without breaking any of the other known transition scenarios. Issue: androidx/media#180 PiperOrigin-RevId: 480866465 (cherry picked from commit 6070d91)
This means the null checker can be more sure that these fields don't get reassigned between a null-check and a usage. PiperOrigin-RevId: 481142004 (cherry picked from commit 248ee46)
PiperOrigin-RevId: 481143798 (cherry picked from commit 026699b)
PiperOrigin-RevId: 481150758 (cherry picked from commit 871a5e6)
PiperOrigin-RevId: 481215581 (cherry picked from commit 6cdaf2c)
PiperOrigin-RevId: 481605567 (cherry picked from commit fd315da)
PiperOrigin-RevId: 481606248 (cherry picked from commit 325e973)
- The naming DefaultMuxer is more consistent with the rest of Transformer codebase (e.g. DefaultEncoderFactory). - By hiding the implementation details of DefaultMuxer, the transition to in-app Muxer will be seamless for apps using DefaultMuxer. - The current plan is that DefaultMuxer will become the in-app muxer. PiperOrigin-RevId: 481838790 (cherry picked from commit b4d7f06)
In exoplayer2 this affects StyledPlayer(Control)View #minor-release PiperOrigin-RevId: 481878940 (cherry picked from commit a5583c0)
#cleanup PiperOrigin-RevId: 481882181 (cherry picked from commit b6bd358)
This is to prepare Muxer to become public PiperOrigin-RevId: 481893842 (cherry picked from commit bd9181e)
(Also, make some public methods private) PiperOrigin-RevId: 481912071 (cherry picked from commit a404fde)
Currently, repeating the same item (via seekNext/Previous) implicitly results in a seek to the default position of the current item, which looks exactly the same as a direct seek. As a result, we don't send onMediaItemTransition as we would for every other seekNext/Previous call. This can be fixed by explicitly marking the repeat case in the internal BasePlayer/ExoPlayerImpl methods, so that the callback can be triggered. Issue: google#10667 PiperOrigin-RevId: 481951788 (cherry picked from commit 76ce0cc)
Before, they used `width` and `height`, which was inconsistent with other pixel tests, and less descriptive. Refactoring change only. No functional change intended. PiperOrigin-RevId: 481970243 (cherry picked from commit 620d8c9)
#minor-release Issue: androidx/media#245 PiperOrigin-RevId: 510456793 (cherry picked from commit a231ff4)
This call may cause performance overhead in some situations, for example if the AudioTrack needs to query an offload DSP for the current position. We don't need to check this multiple times per doSomeWork iteration as the value is unlikely to change in any meaningful way. PiperOrigin-RevId: 510957116 (cherry picked from commit 829b49d)
When rendering frames at a rate higher than the screen refresh rate, e.g. playing at 8x, the player is releasing multiple frames at the same release time (nanos) which are then dropped by the platform. The output buffers are available later and as a result MediaCodec cannot keep up decoding fast enough. This change skips releasing multiple video frames on the same vsync period and proactivelly drops the frame. The frame is counted as skipped rather than dropped to differentiate with frames dropped due to slow decoding. PiperOrigin-RevId: 510964976 (cherry picked from commit cbb6878)
Issue: google#10992 #minor-release PiperOrigin-RevId: 510988140 (cherry picked from commit 57a638a)
The current logic uses manual array operations to keep track of pending changes. Modernize this code by using an ArrayDeque and a data class. This also allows to extend the output stream information in the future. This also fixes a bug where a position reset accidentally assigns a pending stream offset instead of keeping the current one. PiperOrigin-RevId: 511787571 (cherry picked from commit 4e0babd)
PiperOrigin-RevId: 512002735 (cherry picked from commit 1ef70cd)
Protected system broadcasts should not specify the export flag. Marking them as NOT_EXPORTED breaks sticky broadcasts in some cases. Issue: google#10970 #minor-release PiperOrigin-RevId: 512020154 (cherry picked from commit 34b9824)
This test became flaky after google@cbb6878 because some of the unrealistic frame times ended up on the same release time. Using realistic numbers avoids the flakiness. PiperOrigin-RevId: 512566469 (cherry picked from commit 13700e0)
The output info for a new stream is marked pending until the last sample of the previous stream has been processed. However, this fails if the previous stream has already been fully processed. We need to detect this case explicitly to avoid signalling the output change one sample too late. #minor-release PiperOrigin-RevId: 512572854 (cherry picked from commit 39935d7)
Some devices were reported to have wrong PerformancePoint sets that cause 60 fps to be marked as unsupported even though they are supported. Issue: google#10898 #minor-release PiperOrigin-RevId: 512580395 (cherry picked from commit 04f0cc9)
MediaCodecRenderer currently has two independent paths to trigger events at stream changes: 1. Detection of the last output buffer of the old stream to trigger onProcessedStreamChange and setting the new output stream offset. 2. Detection of the first input buffer of the new stream to trigger onOutputFormatChanged. Both events are identical for most media. However, there are two problematic cases: A. (1) happens after (2). This may happen if the declared media duration is shorter than the actual last sample timestamp. B. (2) is too late and there are output samples between (1) and (2). This can happen if the new media outputs samples with a timestamp less than the first input timestamp. This can be made more robust by: - Keeping a separate formatQueue for each stream to avoid case A. - Force outputting the first format after a stream change to avoid case B. Issue: google#8594 #minor-release PiperOrigin-RevId: 512586838 (cherry picked from commit a02c8d8)
Playback parameter signalling can be quite complex because (a) the renderer clock often has a delay before it realizes that it doesn't support a previously set speed and (b) the speed set on media clock sometimes intentionally differs from the one surfaced to the user, e.g. during live speed adjustment or when overriding ad playback speed to 1.0f. This change fixes two problems related to this signalling: 1. When resetting the media clock speed at a period transition, we don't currently tell the renderers that this happened. 2. When a delayed speed change update from the media clock is pending and the renderer for this media clock is disabled before the change can be handled, the pending update becomes stale but it still applied later and overrides any other valid speed set in the meantime. Both edge cases are also covered by extended or new player tests. Issue: google#10882 PiperOrigin-RevId: 512658918 (cherry picked from commit d363977)
Once the value returned from AudioTimestampPoller advances, we only need getPlaybackHeadPosition to sample sync params and verify the returned timestamp. Both of these happen less often and we can avoid calling getPlaybackHeadPosition if we don't actually need it. PiperOrigin-RevId: 512882170 (cherry picked from commit 4cf7d3c)
#minor-release PiperOrigin-RevId: 512890813 (cherry picked from commit 13a86b3)
#minor-release PiperOrigin-RevId: 512897269 (cherry picked from commit 48047cf)
These are not supported by Dackka #minor-release PiperOrigin-RevId: 513176533 (cherry picked from commit ef5a1ce)
…or_entire_file PiperOrigin-RevId: 513213229 (cherry picked from commit d2ba290)
Add some additional information which methods to override for available commands. #minor-release PiperOrigin-RevId: 513251805 (cherry picked from commit a64a9e6)
PiperOrigin-RevId: 513482096 (cherry picked from commit b634005)
#minor-release PiperOrigin-RevId: 513488487 (cherry picked from commit 3b16231)
PiperOrigin-RevId: 513516267 (cherry picked from commit 658b503)
#minor-release PiperOrigin-RevId: 513533248 (cherry picked from commit af6807d)
#minor-release PiperOrigin-RevId: 513555559 (cherry picked from commit 4f68f89)
szaboa
approved these changes
Mar 21, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
https://dicetech.atlassian.net/jira/software/c/projects/DORIS/issues/DORIS-1730