UnstableApi everywhere

[kvillnv]

Hello,

I have been using and updating Exoplayer for 6 years now. I mostly use it for DASH streaming with Widevine DRM.
Today I am migrating from exoplayer to media3 v1.1.0. I started by the migration script and now I am cleaning up.

With Media3, almost everything I migrated has an @UnstableApi annotation.

• Usual methods such as: setBandwidthMeter, setSeekParameters, setUserAgent, DashMediaSource.Factory ...
• Even Using the ExoPlayer.Builder(context, customRenderersFactory)
• Even the trackSelector.parameters
• Even some basic methods like playerView.hideController() is marked as UnstableApi... or setShowSubtitleButton(true)
• And a lot more...

All of this feels very strange. Am I missing something?

Of course I understand I can add @OptIn everywhere or in my lint or gradle, but I would like to know if there is a whole new implementation that would be "Stable API".

I have 3 questions, but feel free to reply to Q3 later, as I am more interesed in Q1 and Q2 today.

Q1.

Is there a new stable way I am supposed to implement? I can't find documentation about this. Instead of using the UnstableApi methods are there replacement "Stable API" methods somewhere? Is there a remplacement for Exoplayer class? Even the new media3.ui.PlayerVIew is marked Unstable everywhere.
Otherwise is there a new way coming up? I wonder if I am better off staying with exoplayer library for now.

Q2.

Why do we have so much UnstableApi on methods we have been using as stable for a while with exoplayer?

Q3.

This might be a regression. I was accessing some drawables in the PlayerControlView, but they are now private: for example when going fullscreen with gesture. I would change an imageResource in the PlayerView this way:

playerView.findViewById<ImageButton>(R.id.exo_fullscreen)
                .setImageResource(R.drawable.exo_icon_fullscreen_exit)

R.drawable.exo_icon_fullscreen_exit has become private.
What would be the replacement for that, in order to stay future proof using Exoplayer icons? My project is using Jetpack Compose.

Please enlighten me.
Thanks.

[icbaker]

Thanks for the questions - I appreciate the @UnstableApi stuff looks like a big change from exoplayer2.

The most important thing to note is that none of Media3 is less stable than exoplayer2 - there's some more info on that here: #331 (comment)

I have just (in response to this issue) added a section to the Media3 migration guide to make this clearer, and to provide some more context about why these lint errors suddenly appear after the Media3 migration.

The stable API is intended to serve common media use-cases. We don't currently plan to add deep customization points in the library into the stable API.

---

Tackling some of your specific questions:

Is there a new stable way I am supposed to implement?

That depends on exactly what you're doing. As I said above, there are 'stable' solutions for common media use-cases, and we plan to add more in future. It may be that there is a stable alternative for what you're doing, or we can consider stabilizing the APIs you're using, or you may be doing something that is a bit more 'custom' than we want to stabilise at this point. If you can provide some specific details of what you're doing that you think should be part of the stable API we can provide some more specific guidance.

Is there a remplacement for Exoplayer class?

The ExoPlayer interface is not unstable. Some of its methods are, as are some of the methods on ExoPlayer.Builder. There is no replacement for ExoPlayer, we expect you to use this interface as part of using the library. If there are unstable methods on ExoPlayer that you think should be in the stable API, please provide the context of what you're trying to do and we can consider the best way forward.

• Usual methods such as: setBandwidthMeter, setSeekParameters, setUserAgent, DashMediaSource.Factory ...

We would consider many of these quite custom operations - for example we would expect most playback use-case to be able to use DefaultMediaSourceFactory and not need to interact directly with DashMediaSource.Factory. Similarly for DefaultBandwidthMeter.

• Even Using the ExoPlayer.Builder(context, customRenderersFactory)

Similarly - providing a custom renderer integration is certainly quite a high level of customization of the library.

• Even the trackSelector.parameters

TrackSelectionParameters is part of the stable API. Are you referring to the DefaultTrackSelector here? We would expect most common track selection operations to be possible using the stable parts of TrackSelectionParameters, so could you please provide more details about what you're needing to do here?

• Even some basic methods like playerView.hideController() is marked as UnstableApi... or setShowSubtitleButton(true)

These seem like reasonable candidates for adding to the stable API, thanks for flagging.

Why do we have so much UnstableApi on methods we have been using as stable for a while with exoplayer?

I think this is explained above, and in the new section of the migration guide: exoplayer2 wasn't stable.

I was accessing some drawables in the PlayerControlView

There is no drawable with that name related to the Media3 PlayerControlView (which was called StyledPlayerControlView in exoplayer2). It's important to note that the exoplayer2 PlayerControlView is called LegacyPlayerControlView in Media3. There is a drawable named exo_styled_controls_fullscreen_exit used in Media3 PlayerControlView, but it's not listed in the class-level javadoc of the class as being supported for override, so it's not supported (it may work today, but isn't guaranteed to work in future versions of the library). If you want to change the full-screen state of the PlayerView 'out of band', that is tracked by google/ExoPlayer#10391

[icbaker]

Closing because I think the general questions have been answered, and some docs have been clarified. If you have specific requests for additions to the stable API please file new issues with detailed context and we'll take a look - thanks!