Refactor exoplayer deprecations

[CHaNGeTe]

Please check carefully for possible breaking changes.
This PR removes exoplayer deprecations in order to be able to upgrade easier to exoplayer 2.10.

TODO (need help):

• SingleSampleMediaSource (https://github.com/react-native-community/react-native-video/blob/fa1e36ad3e99e092931bd23f6511aa41ced1b9a7/android-exoplayer/src/main/java/com/brentvatne/exoplayer/ReactExoplayerView.java#L433)
• AdaptiveTrackSelection.Factory (https://github.com/react-native-community/react-native-video/blob/fa1e36ad3e99e092931bd23f6511aa41ced1b9a7/android-exoplayer/src/main/java/com/brentvatne/exoplayer/ReactExoplayerView.java#L336)

[cobarx]

@danielmarino24i Man, it's really nice to see these deprecated functions going away. Nice work.

I'm not sure what the easiest way to send you the code recommendations, so I'm pasting them inline:

SingleSampleMediaSource

        return new SingleSampleMediaSource.Factory(mediaDataSourceFactory)
            .createMediaSource(uri, textFormat, C.TIME_UNSET);

I tested this with some sideloaded subs and this code is working fine.

AdaptiveTrackSelection.Factory

TrackSelection.Factory videoTrackSelectionFactory = new AdaptiveTrackSelection.Factory();

I don't believe the bandwidth meter is doing anything particularly important.

[CHaNGeTe]

Added your suggestions, bandwidth meter is now configured on the exoplayer instance

[CHaNGeTe]

Seems, if I didn't miss any, that all deprecations are gone now

[kristerkari]

@CHaNGeTe Are you planning on updating to a newer version of ExoPlayer, and if so, is there going to be another 4.x release?

I'm just thinking that updating to a newer ExoPlayer version might fix the crash that I have reported earlier: #1633

[CHaNGeTe]

@kristerkari I am doing tests with com.google.android.exoplayer:exoplayer:2.10.3

But as it has AndroidX support, and they have migrated to androidx.compat, seems it will be released as 5.x

[kristerkari]

Ok, thanks for the info! Then we have to get React Native updated to the latest version first before being able to fix the crash.

[CHaNGeTe]

I think update of RN is not required to test it.

I mean, for real AndroidX support I think you have to, but to compile the app with libraries with androidX support you don't need to migrate to RN >=0.60

[kristerkari]

I think update of RN is not required to test it.

I mean, for real AndroidX support I think you have to, but to compile the app with libraries with androidX support you don't need to migrate to RN >=0.60

Oh that's great to hear, I was under the impression that updating to 5.x requires RN 0.60

[CHaNGeTe]

I think it is recommended, but I am testing with "react-native": "0.59.5",

[benoitdion]

we should also update how the bandwidth meter is created. Looks like new DefaultBandwidthMeter() misses a lot of the smart defaults we get when using the builder that takes a context.

[CHaNGeTe]

https://medium.com/google-exoplayer/https-medium-com-google-exoplayer-simplified-bandwidth-meter-usage-17d8189f978b

Sth like this?

SimpleExoPlayer player = ExoPlayerFactory.newSimpleInstance(context);

DataSource.Factory dataSourceFactory = 
    new DefaultDataSourceFactory(context, userAgent);
MediaSource mediaSource = 
    new DashMediaSource.Factory(dataSourceFactory)
        .createMediaSource(uri);

player.prepare(mediaSource);

[benoitdion]

That looks right although it'd be nice to reuse the bandwidth meter between plays. I believe that's why it's currently a static variable.

Maybe outside the scope of this PR but what do you think about creating a ReactVideoPackageConfig class that exposes the exoplayer configuration. There would be a default implementation that uses the exo defaults and each application could override the config by passing a config object when instantiating ReactVideoPackage.

[benoitdion]

This was done in #1753! We'll release the change in a 5.1-alpha