-
Notifications
You must be signed in to change notification settings - Fork 1.9k
[F100] MediaPlayer View #1692
Comments
Android's stock video view isn't great, especially on older APIs and devices. I'm not sure if it's a good idea for Xamarin to create a cross-platform video player unless you're willing to put some serious effort into making a professional-grade control. I believe Google is now using ExoPlayer for YouTube and possibly other apps as well. https://www.youtube.com/watch?v=6VjF638VObA If you decide to go forward with a video view, can you leverage ExoPlayer for Android? Also, @martijn00 and others have contributed to ExoPlayerXamarin and XamarinMediaManager which can be utilized instead. |
Would also like your input here @martijn00 :) Is it wise to make this part of the XF framework? Because I would be leaning to a no on this one. It's incredibly complex, and are you sure the team is up to committing to this level of work/maintenance? |
I agree that there is complexity here and the urgency to implement this is minimal. If such a thing were to be designed properly and done, fine. It is rather unlikely we will implement this ourselves. |
A video and audio playback control is a must. It doesn't have any UI beside actual video rendering. No volume controls, no seek bar, nada. We need to define exactly what to support. |
The UWP media element does have UI other than the video. You can hide the transport controls, but they are available. |
@hartez Correct. I was referring to older XAML platforms (WPF, WindowsPhone, Silverlight). I guess they added it in UWP because of the unified platform idea which means unified look and feel too |
So here's my thinking, as of right now: if vanilla, out-of-the-box XF supports a media player element, it will be a basic one which utilizes the built-in native media players. Like, very, very basic. For advanced scenarios, bells-and-whistles, etc, developers will need to look at plugins (like the ones Adrian mentioned upthread) or write custom renderers. That's the scenario I'm currently targeting. |
@hartez I think that's what I said too. |
The stuff under "Difficulty" is still relevant; at the very least, the control has to play nice with system audio events. For example, when a call comes in, the native player needs to respond by ducking or pausing; that change in state has to be reported up to the Forms control. |
Is this thread a request to make https://github.com/martijn00/XamarinMediaManager official, or to copy over code from that project, or to write a new forms media player from scratch? |
I agree with @andreinitescu that we should have a cross-platform media player (whose playback controls can be hidden when needed). Whether it will be basic or advanced is another issue, and on a personal level, I don't care if this control is part of XF or a third-party plugin. It looks like @martijn00 doesn't have the time to commit to working on XamarinMediaManager which has NOT seen a new release in 7 months. My concern with a basic control is that it becomes yet another impediment among others for XF developers to create a serious production app. Video is quite hot on mobile now, and things like live streaming are becoming prevalent across many apps. My recommendation for the team would be hiring Martin to work on XMM. See here. @davidortinau Would love to hear your opinion. |
@adrianknight89 In the first version of this control, I'd not put any playback controls at all, just how WPF and Silverlight works. My suggestion is to align with UWP MediaElement: Events: MediaOpened, MediaEnded, MediaFailed, CurrentStateChanged, BufferingProgressChanged This will be enough to enable cross platform media playback. Adding your own playback controls will be easy, and you can give any look and feel you want. In next iterations of this control, add more features including builtin playback controls. |
@adrianknight89 I'm personally using @martijn00's project. I say we support @martijn00 over there. I would like to see this in Xamarin.Forms down the road. As for how basic or advanced, what's your definition there @adrianknight89 ? What 2 or 3 features would you say are "must have" that you are concerned would be cut if we delivered a v1 basic? |
I agree with you on supporting @martijn00. XamarinMediaManager could be the video player all of us leverage similar to how FFImageLoading has become quite popular. What I consider basic is the minimum cross-platform functionality that people will need (e.g. play, pause, stop, repeat/reset, and volume). For me, [1] an advanced scenario is HTTP Live Streaming (HLS). As far as I know, Android's https://academy.realm.io/posts/360andev-effie-barak-switching-exoplayer-better-video-android/
As mentioned above, ExoPlayer has a steep learning curve even for Android developers despite the documentation available today. Xamarin could make it easier for us to use it. Other (semi) advanced features would be [2] subtitles, annotations, playback speed, and fullscreen (though to some, the last one should be part of basic functionality). Another thing is, [3] portrait only apps should be able to show video on landscape while all other pages on the stack do not trigger SizeChanged events. [4] I'd also like to see the ability to stop playback when earbuds are unplugged and when you get out of car (presumably after bluetooth connection is dropped). [5] Aspect ratio/mode should be handled properly (i.e. let us choose between various modes). [6] Finally, just like Spotify/YouTube does it, there should be a way for us to let users choose output device when there are multiple sources available simultaneously (phone speakers, portable home devices, car speakers, etc.) For my personal use case, I'd like to see in v1 everything in basic as well as [3], [4], and [5]. The other features can come in later. EDIT: We should also test the media player to ensure it can be embedded in a |
I agree with this list as the essentials, minus CurrentStateChanged and BufferingProgressChanged. I would also suggest that these should all be instance properties on a media View. (Or an audio object if that is separate.) MediaManager has had the most development, but has the above as static methods, e.g. CrossMediaManager.Current.Play. InTheHand.Forms is also worth looking at. |
We're using inthehand.forms for media playback. I think the implementation would be perfect for a basic video player in XF. It is a quite basic control, but does exactly what you want for basic playback. It has events, handles aspect ratio correctly. Has an option for showing/hiding default controls and supports custom http headers for a http source, which come in handy if you are streaming video from an api. |
Rationale
Forms does not currently have a simple cross-platform way to play audio and video without creating a custom renderer.
Implementation
This will probably require a
MediaSource
class similar to theImageSource
class, with the appropriate subclasses (FileMediaSource
,StreamMediaSource
,UriMediaSource
and their respective type converters).The actual
MediaPlayerView
should have a bindable propertySource
ofMediaSource
. The renderers for each platform should use native media players.The
MediaPlayerView
should have a boolean propertyControlsVisible
; when set tofalse
, the transport/playback controls of the native player should be hidden.The view should have a property
PlaybackState
with possible enum valuesUnknown
,Paused
, andPlaying
.The view should expose events for
PlayRequested
PauseRequested
PlaybackStateChanged
Renderers should respond to
PlayRequested
by attempting to play the source media in the native player. They should respond toPauseRequested
by attempting to pause the media. Changes in native playback state should raisePlaybackStateChanged
in theMediaPlayerView
.The
MediaPlayerView
should includeSendPlay()
andSendPause()
methods for raising thePlayRequested
andPauseRequested
events.The initial version of this control will not support background playback for audio.
Backward Compatibility
This is a brand new View, so there should not be any backward compatibility issues.
Difficulty: Very
In addition to playing audio/video, this control also needs to gracefully support incoming call interruption, system-wide audio requests, volume controls (software and hardware), and keeping the screen active during playback. All of these interactions are different on each platform.
The text was updated successfully, but these errors were encountered: