- 25 Jan, 2023 5 commits
-
-
Added new method to check if codec just functionally supports a format. Changed getDecoderInfosSortedByFormatSupport to use new function to order by functional support. This allows decoders that only support functionally and are more preferred by the MediaCodecSelector to keep their preferred position in the sorted list. UnitTests included -Two MediaCodecVideoRenderer tests that verify hw vs sw does not have an effect on sort of the decoder list, it is only based on functional support Issue: google/ExoPlayer#10604 PiperOrigin-RevId: 487779284 (cherry picked from commit 1eb8a6b3)
michaelkatz committed
- 05 Jan, 2023 1 commit
-
- 24 Nov, 2022 1 commit
-
- 23 Nov, 2022 2 commits
-
-
r2.18.2
Michael Katz committed -
PiperOrigin-RevId: 490263003 (cherry picked from commit 202e03fc)
christosts committed
-
- 22 Nov, 2022 5 commits
-
-
#minor-release PiperOrigin-RevId: 490202192 (cherry picked from commit 6f1cf6da)
michaelkatz committed -
#minor-release PiperOrigin-RevId: 489959918 (cherry picked from commit ca190c08)
michaelkatz committed -
#minor-release PiperOrigin-RevId: 489202167 (cherry picked from commit 7e82d4ec)
michaelkatz committed
- 17 Nov, 2022 7 commits
-
-
Util.getAudioTrackChannelConfig() maps a channel count to a channel mask that is passed to AudioTrack. The method expected that playback of 8-channel audio is possible from Android 5.1 and playback of 12-channel audio is only possible from Android 12L. However, there is no restriction on the upper number of channels that can be passed to the AudioTrack. google/ExoPlayer#10701 is an example where the audio decoder outputs 12 channels on an Android 10. This change removes the restrictions for 8 and 12 channels. Note, we still do not support playback of arbitrary number of channels as it would require further changes to DefaultAudioSink. #minor-release Issue: google/ExoPlayer#10701 PiperOrigin-RevId: 488659831 (cherry picked from commit 1b24e6fd)
christosts committed -
When we currently trigger the iteration finished event during the release, we don't mark the event as triggered. This means that someone can trigger another release from within the callback, which then tries to resend the event. Issue: google/ExoPlayer#10758 #minor-release PiperOrigin-RevId: 488645089 (cherry picked from commit 3e5103a3)
tonihei committed
- 10 Nov, 2022 9 commits
-
-
Without this the annotation isn't shown in javadoc (same in Dackka) No annotation: https://exoplayer.dev/doc/reference/com/google/android/exoplayer2/source/DefaultMediaSourceFactory.html#getSupportedTypes() Annotation present: https://exoplayer.dev/doc/reference/com/google/android/exoplayer2/source/MediaSource.Factory.html#getSupportedTypes() #minor-release PiperOrigin-RevId: 487498450 (cherry picked from commit 4949fbe5)
ibaker committed -
#minor-release PiperOrigin-RevId: 487479366 (cherry picked from commit 09bee98b)
christosts committed -
This uses `@hide` on `protected final` methods to hide them from Dackka javadoc generation, since these methods are inaccessible to developers anyway. These symbols will still (currently) be included in artefacts distributed on Maven (because we don't run Metalava as part of generating these artefacts). In some cases I had to change the visibility/finality of methods to make them `protected final` before adding the `@hide` annotation (but the impact should be very low, since most of these methods were either already unusable by app developers, or they shouldn't have been used). #minor-release PiperOrigin-RevId: 487472907 (cherry picked from commit 1cd488ac)
ibaker committed -
This makes two fixes: 1. Remove `HlsSampleStreamWrapper.Callback` (package-private) from the list of interfaces implemented by `HlsMediaPeriod` (`public`) and move the implementation to a private inner class instead. This avoids Metalava complaining about a public class that inherits from a package-private type. 2. Reduce the visibility of `RtpPayloadFormat.isFormatSupported(MediaDescription)` from `public` to package-private. The `MediaDescription` type is already package-private, so this method was already unusable outside the package. #minor-release PiperOrigin-RevId: 487472781 (cherry picked from commit 9041d7b9)
ibaker committed -
This makes two types of fix: 1. Align parameter names on overridden methods where the superclass has `@param` javadoc. 2. Use `@hide` on `protected final` methods that refer to package-private types. This will hide these symbols from Dackka javadoc generation but not (currently) from the artefacts distributed on Maven. These methods are currently unusable outside their package anyway (e.g. by external developers) because of the dependency on a package-private type. This also changes some HLS, SmoothStreaming, and IMA code where I've renamed parameters of overridden methods to be consistent across the type hierarchy. #minor-release PiperOrigin-RevId: 487472665 (cherry picked from commit 10c4a4df)
ibaker committed
-
- 09 Nov, 2022 6 commits
-
-
Also, document that we tone map when no HDR features are explicitly set PiperOrigin-RevId: 487310971 (cherry picked from commit 8bdd2784)
huangdarwin committed -
Not setting the color info results in a missing "colr" box in the produced container, under file/moov/trak/mdia/minf/stbl/stsd/hvc1. This means extractors will not be able to find out the transcoded file is HDR. In `Transformer`, this means it can't transcode this transcoded file, because it currently relies on the container bearing HDR info to construct the transcoding sample pipeline. PiperOrigin-RevId: 487276712 (cherry picked from commit d6c8e3a8)
claincly committed -
In startTransformation method we were throwing UnsupportedEncodingException (IOException) when mediaItem with unsupported arguments is passed. Changed this to IllegalArgumentException which seems more logical here. PiperOrigin-RevId: 487259296 (cherry picked from commit 4598cc92)
sheenachhabra committed -
Imported from GitHub PR Issue: google/ExoPlayer#10762 This ensure that ffmpeg error code are properly translated to values that the ExoPlayer decoder understand. The main gain is that it allows the decoder to properly ignore more cases of invalid data and recover. The second gain is that the other errors are now proper ExoPlayer errors and no more obscure buffer ones. Fixes: Issue: google/ExoPlayer#10760 Merge 82ceeb77d6df71f5ffb0474db66a36fd6eb8e51a into 972e169b COPYBARA_INTEGRATE_REVIEW=go/exoghi/10762 from Tolriq:ffmpeg_error_code 82ceeb77d6df71f5ffb0474db66a36fd6eb8e51a PiperOrigin-RevId: 487189910 (cherry picked from commit 6d2e7a1b)
Tolriq committed
-
- 08 Nov, 2022 2 commits
-
- 07 Nov, 2022 2 commits
-
-
Problem: We are initialising muxer as soon as we start the transformation. Now the startTransformation() method can be called from main thread, but muxer creation is an I/O operation and should be not be done on main thread. Solution: Added lazy initialisation of muxer object. The actual transformation happens on background thread so the muxer will be initialised lazily from background thread only. Another way was to provide an initialize() method on MuxerWrapper which will explicitly initialise muxer object but with this approach the caller need to call the initialise method before calling anything else. With current implementation the renderers are calling MuxerWrapper methods on various callbacks (Not sequentially) and also we are sharing same muxer with multiple renderers so It might become confusing for the caller on when to call the initialise() method. Also there are few methods on MuxerWrapper which dont really need muxer object. So in short it might make MuxerWrapper APIs more confusing. Validation: Verified the transformation from demo app. PiperOrigin-RevId: 486735787 (cherry picked from commit b10b4e6d)
sheenachhabra committed -
This should be necessary to ensure decoders see fewer errors. Setting this resulted in removing native_dequeueOutputBuffer errors on OMX.MTK decoders for in-app tone mapping prototyping. PiperOrigin-RevId: 486715941 (cherry picked from commit 0b7e5bba)
huangdarwin committed
-
