React-native-video: Proposal: Stay lean, focus on iOS and Android (drop Windows and DOM support)

[jenshandersson]

Me and @CHaNGeTe were discussing the future of this amazing project. We want to reconsider the multi platform support and focus on the majority, iOS and Android. This means dropping support for DOM and Windows (or extracting to separate repos). It would also be nice to drop support for Android MediaPlayer and only focus on ExoPlayer.

The main reason for this is to make the project leaner, more stable and be able to move faster.

There are a lot of people depending on this library, but just a few maintaining it. Please let us know your thoughts on this. Ideally we create a new version where we drop the support, so people can decide to stay or move towards the future of video playback! 🚀

[CHaNGeTe]

I suggest adding audio playback to the discussion

[cobarx]

What do you feel we gain by dropping support for these other platforms? The approach I had taken was to not put any effort into new development for the other platforms but if people submitted PRs, I'd take them. Is the main concern the example projects?

There are a fair number of people that didn't ever switch over to ExoPlayer for whatever reason, so that code needs to continue to be available in some capacity or another. No idea if there are people using it on Windows, I'm sure there are a few.

As far as audio goes, I'd love to see that dropped. I have no idea why people are using this lib for audio rather than a dedicated audio lib like react-native-track-player. The main support issue I've seen is background audio. I'm not sure if that has any video use cases, the only thing I could think of might be Picture in Picture, but probably not. Definitely don't put in any support for new audio features. I guess you could completely eliminate audio only support and tell people to switch to a dedicated audio lib.

With all this stuff, just realize that dropping support will create some headaches for people especially if they have an app that's already out there and they're not putting a lot of work into maintaining it. Suddenly they see that MediaPlayer or Windows is gone and they aren't sure what to do. Not to say don't do it, but do consider the impact it will have.

[canyavall]

I think one of the reason that React ecosystem works is because it foucs on small targets. Focusing on android + ios + windows + exoplayer + android mediaplayer + audio having not a lot of maintainers can be an issue

In my point of view, I think it is better to freeze the project as it is right now and focus on what most people is using. Then, if some people is using it for web (the are multiple players already focusing to web) or android mediaplyer, they can create a fork of this component and from the fork a new library focusing only on android mediaplayer or web.

So, in our case (as we use it in a company project), exoplayer + IOS + Android as @jenshandersson proposed would be perfect

[jenshandersson]

@cobarx I feel that if a library supports multiple platforms then they should have feature parity. Right now the library feels a bit all over the place, features are added to one platform but not others.

I agree with dropping audio only support. But background audio support is required for background video support, and I feel this is a key feature.

One way forward could be keeping the support but officially only maintaining ExoPlayer and iOS. But that wouldn't be my preferred way forward.

Proposal

Start working on a 5.0.0 version where we remove DOM, Windows, Android MediaPlayer, Audio only playback. We focus on delivering a great experience on ExoPlayer and iOS. This will allow us to easier clean up the code and repo (hopefully closing the 500+ issues). We keep a consistent interface between the platforms.

Freeze 4.x and allow people to keep using it. This way people who use Windows and DOM can keep using the lib. (We could consider releasing new versions for bug fixes etc?)

Thoughts? (or just leave a 👍if you like this proposal)

[gazedash]

@jenshandersson wait, what? don't drop the audio only playback

[jenshandersson]

@gazedash this is just a discussion right now :) Can you please explain why you'd use a video library for audio playback? Instead of eg react-native-track-player like @cobarx suggested above.

Since we still need _background audio_ for background video, maybe we might as well keep the audio only playback? (ping @cobarx @CHaNGeTe )

[cobarx]

Here's my recommendation:

react-native-dom

React out to Vincent Remier over at react-native-dom and see if he'd like to fork the repo and maintain a copy of the video player for DOM uses as something like react-native-video-dom. There's probably very few people using this (I built it for a project that we didn't end up taking to production) so I doubt it will be missed.

Android MediaPlayer

Because there are a fair number of people using this, there needs to be some kind path where people can keep their app the way it is or gradually migrate over. Fork this into react-native-video-legacy and let someone who wants to maintain it take it over. Actively work to address issues where MediaPlayer has advantages over ExoPlayer so that code branch can fade into obsolescence.

Windows

It would be pretty nice to be able to support all of the major React Native platforms. React out to someone at Microsoft and see if they have anyone on their team who would be interested in helping to maintain this. I can talk to people within our org and see if we have any connections over at Microsoft or Windows dev who might want this role. If nobody steps up, fork it off.

Note:
I think there is a lot of value in supporting tvOS and Android TV, so those should still be officially supported platforms. Many of the apps I've worked on would love to have TV support. To get large corporate & Silicon Valley apps to adopt react-native-video this needs to be there.

[n1ru4l]

Just got a notification from this thread which reminded me that some people have issues with exoplayer and fall back to the Mediaplayer.

https://github.com/react-native-community/react-native-video/issues/1318

Stuff like this should get addressed before removing Mediaplayer.

[CHaNGeTe]

@n1ru4l you linked this same issue

[n1ru4l]

I meant https://github.com/react-native-community/react-native-video/issues/1318 sorry.

[jonathangreco]

This project is impressive, and important. It must continue to evolve.
But currently this project is completely overwhelmed by bug reports.

Any proposal that will bring stability and accelerate progress is welcome.

Some bugs are more than 10 months old and are quite relevant. Where a solution could have been proposed during the week, the delay is abnormally high and blocks many javascript developers (they can't contribute if they are not native experts). Unfortunately, and hopefully, the community has nothing as good as this component and therefore get blocked when their issues are not resolved during months.

I fully understand that an open source library is developed by people on their free time. And I also understand all the difficulties involved in having to satisfy an open source community on a project as central as it is necessary.

So I completely agree with this proposal and I hope that it will be able to attract new contributors at the same time as it will make this library stable.

I'm not a native English speaker, if some of my sentences are rude, it's not on purpose. Sorry in advance if it's the case.

[benoitdion]

Android MediaPlayer does seem like it falls into the legacy category and it'd make a lot of sense to deprecate with the next major version.

It'd be nice to keep windows support active but without an active maintainer, it does seem like it could slow down the rapid evolution of the core platforms.

Regarding ios and android support, I agree with what others have said it'd be great to continue supporting advanced features like audio only, background playback, etc. I've been thinking about a plugin/extension system that could make such features optional. This could also help with some of the less popular platforms where only "core" would be supported but only some of the extensions would be implemented.

[benoitdion]

As far as audio goes, I'd love to see that dropped. I have no idea why people are using this lib for audio rather than a dedicated audio lib like react-native-track-player. The main support issue I've seen is background audio. I'm not sure if that has any video use cases, the only thing I could think of might be Picture in Picture, but probably not. Definitely don't put in any support for new audio features. I guess you could completely eliminate audio only support and tell people to switch to a dedicated audio lib.

Our app relies on react-native-video for audio only, video and background playback and can switch from audio only to video. Using the same library to power all these experiences is a major win.

[canyavall]

So, there's ny final decision about this topic? I think it is, probably, one of the most important topics to discuss about and find a proper solution ^_^

[OlegNovosad]

I vote for keeping it simple supporting only iOS and Android and only video related stuff.

We are using this library for playing video streams, have to use another one for YouTube videos and another for video controls and its overhelming.

However you could keep this focused and suitable for all video playing cases with great performance, stability and so on.

P.S. When you type "react-native video player" you always get here. And semantically when people type "react-native" they are looking for mobile specifics ;-)

[CHaNGeTe]

Hey guys, what do you think on autolinking exoplayer version for RN > 60.
I think it makes more sense than android

https://github.com/react-native-community/react-native-video/issues/1747

[benoitdion]

This issue has received a lot of feedback now so I'd like to propose a few concrete next steps:

1. Aggressively triage old issues and PRs. For PRs, close duplicates and ask the developer if they'd like to bring the PR up to date with master.
2. Start merging PRs for minor bugs and feature improvements. Release every change to 5.1-alpha.
3. Target a 5.1 release within ~1 month, say by end of October. Peloton will be committing dev time during work hours so this should be more than achievable. 5.1 will be the last release with windows, dom and android MediaPlayer support. If there's support for it, we can continue releasing critical bug fixes for those platforms on 5.1.x.
4. Remove support for windows, dom and android MediaPlayer from the repo, release 6.0.

Unless there's any major pushback, we'll start working on 1. and 2. next week :).

[CHaNGeTe]

I am placing PRs (merging them, but not releasing them) to master, by now Changelog entries are set to next

[dillingham]

+1 for not removing audio only. Lots of blogs linked me here and I tried other packages and none were as easy to get up and running.. or maybe a linked extracted package..

[vladp]

With regards to autlinking
".. Hey guys, what do you think on autolinking exoplayer version for RN > 60.
I think it makes more sense than android .."

I find that autolinking in both react-native-community/cli and
in react-native-unimodules is completely broken for non-trivial monorepo projects

In monorepo projects location of package.json is not just ../../ compared to the android app location.
Instead it can be at a parent or sibling directory, and there are more than one node_modules (some times). There is also not a 'standard' MainApplication.java where the list of packages can be 'injected'.

These two projects ( react-native-community/cli and react-native-unimodules ) made some efforts to accomodate monorepo projects, but not nearly enough to make support working. Instead builds break right away, require days of troubleshooting, and then at the end packages under autolink 'spell' cannot be used.

So if anything, the autolinking thing would be a step back.

Truth is, probably, that automatic discovery and linking that works for RN universally, require a formalized build system like 'webpack' or metro in level of complexity, and it is simply unattainable with the effort that one or two package maintainers can put into it.

[Ashoat]

I'd like to argue against deprecating MediaPlayer support on Android.

There remain several issues with the newer ExoPlayer, particularly with older Android devices, some of which may be issues with this project's implementation rather than ExoPlayer itself.

1. As @n1ru4l mentioned, ExoPlayer straight up doesn't work in some cases, and has some performance concerns (#1318)
2. Exoplayer doesn't always pick up the correct orientation on older Android devices (#1213, #842, #808). This seems to be an issue with the native APIs themselves, as you see a lot of StackOverflow issues on this subject
3. The current implementation of android-exoplayer doesn't support returning the video's real dimensions (#1530). Currently the naturalSize reported by onLoad is just pulled from the on-screen React container's dimensions, in contrast with the MediaPlayer approach where it is sourced from the actual video. ExoPlayer does support pulling the dimensions from the video, but it's a bit more complicated. This matters in particular because on older Android devices, the system media APIs can return incorrect dimensions, and the EXIF information can be unreliable. @react-native-community/cameraroll and expo-media-library both have this issue

It's worth noting that ~10% of Android users worldwide are still on Android 4.4 or earlier. When you scope to people in the West using apps like Peloton, of course that number will be much smaller. But for a lot of people in the developing world, React Native's ability to support older Android devices is crucial. If react-native-video stopped being viable for the developing world it would be a huge hit for the React Native ecosystem as a whole.

[vforvasile]

When analyzing an AAB I saw some files related to shaka-player from the DOM version that get bundled in Android app, probably iOS as well, didn't check yet.

[stmoy]

👋 Hello from the React Native team here at Microsoft! We have been actively working with Facebook to make Windows a "1st class citizen" alongside Android and iOS. This is obviously a work-in-progress, but one that we're committed to with our friends at Facebook.

To that end, we have updated the RN for Windows platform to leverage high-performance C++ ("RNW vNext"). Now that the RNW vNext supports native modules as a platform, we have identified several key native modules to add Windows support for (including react-native-video) to help validate that the platform has the right set of capabilities and to bootstrap the community of modules that target Windows.

To that end, we have developer resources here at Microsoft to update react-native-video's Windows implementation to the latest version of React Native for Windows. We're also tracking this work here: https://github.com/microsoft/react-native-windows/issues/2095

Our hope is that Windows support is not removed from react-native-video, as this module is very important for React Native developers including those that target Windows.

[benoitdion]

if there's resourcing to actively support the package I see no reason to drop windows support. Especially since we've failed to execute on a lot of the idea described earlier in this thread. The more active developers, the better at this stage :).

[prashantchothani]

In android media player support should be dropped and only exoplayer should be focused for. Windows support should be there but moved to seperate branch and added only if required. A lean video playback will DRM, custom ui and quality improvements to keep it updated with latest version of the player is most important.