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

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! 🚀

12 thoughts on “Proposal: Stay lean, focus on iOS and Android (drop Windows and DOM support)

  1. 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

  2. @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)

  3. 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.

  4. 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 ^_^

  5. 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 😉

  6. 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 :).

  7. 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.

  8. 👋 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: microsoft/react-native-windows#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.

  9. 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.