Proposal Add MediaElement or MediaView

[insinfo]

• Overview Represents a control that contains audio and/or video. Currently all platforms support video playback in some way, so this "MidiaElement" control can be minimally aligned between platforms.

  1. Natively supported transition effects between one media and another
  2. Supports natively playing a playlist as an input, ie a collection of URIs
  3. Infinite loop reproduction.
  4. Playback seamlessly between one media and another
  5. Video overlay support, for example picture in picture
  6. Support Video and Audio Simple effects

• Scenario The idea here and make life easier for the developer, I believe that everyone in XAML lovers, we want a robust and complete standard and that facilitates the life of the developer so I propose to include these controls as a standard of XAML specification. These are widely used in the real world today. In several areas we find these types of control such as audio/video playes, visual programming, animation software, single/multitracks audio editors, video editors, slide editors, photo gallery, websites, social networks among many others.

• Example in XAML

<MediaElement InfiniteLoop="true" Transition="crossfade" Autoplay="true">
    <PlayList>
        <PlayListItem Index="0" URI="video1.mp4" >
             <VideoEffect Type="BlackAndWhite" Amount="50%"> </VideoEffect>
             <VideoEffect Type="AutoEnhancement" Amount="50%"> </VideoEffect>
        </PlayListItem>
        <PlayListItem Index="1" URI="video2.mp4" >
               <VideoEffect Type="AccentuateContrast" Amount="50%"> </VideoEffect>
        </PlayListItem>
        <PlayListItem Index="3" URI="music1.mp3">
              <AudioEffect Type="ReduceNoise" Amount="50%"> </AudioEffect>
        </PlayListItem>
    </PlayList>
</MediaElement>

• Links/Images

[birbilis]

See SMF and MMPPF - would be nice to diff and merge them, so that one can port existing Silverlight code more easily. Don't see why there should be two separate repos

[insinfo]

@birbilis English is not my native language. I did not understand what you mean exactly. It would be interesting if this control, Natively supported transition effects between one media and another Supports natively playing a playlist as an input, ie a collection of URIs Infinite loop reproduction. Playback seamlessly between one media and another

[birbilis]

SMF=Silverlight Media Framework MMPPF=Microsoft Media Player Platform Framework if I remember the acronyms correctly

Code is on Codeplex that is being shut down (frozen). Would love to see a merging of those on github, since MMPPF came out of SMF

[insinfo]

@birbilis I understood, I updated with a syntax sample what do you think, if I am not mistaken Qt Framework has implemented these features

[insinfo]

@birbilis If I am not mistaken SMF and MMPPF does not have the resources I quoted

[birbilis]

Supports all, even transition effects (via smooth streaming format, guess DASH also supports those - btw I think MMPPF supports DASH but SMF only came up to Smooth Streaming)

[birbilis]

Sorry, meant to say apart from, that is if you mean fade-in etc. Maybe could do those too in that format, not sure. With TimelineMarkers and multiple streams could do fades programmatically though

[insinfo]

From what I researched quickly, there is no support for the features I mentioned https://playerframework.codeplex.com/ https://smf.codeplex.com/

[birbilis]

for which ones? Even PiP was supported from what I remember when looking at SMF code

[mrlacey]

Is this intentionally meant to be a wish list item for one-day inclusion? If so, you should make this clear.

If not, then this seems way off from the ubiquity principle.

• Xamarin.Forms doesn't currently have a MediaElement or equivalent.
• Even UWP, which does have a MediaElement control, doesn't have support for most of what you're proposing.
• It seems you're just defining a new control (or control capabilities that you'd like to be available everywhere. If this were included it would be forcing platforms to add APIs and functionality to meet the standard. This is not the point of XAML Standard. As per the principles (which I humbly suggest you re-read) the aim, at least initially, is to provide a common markup to existing widely used APIs and not to create a wishlist of APIs and controls for all platforms to provide.

[Mike-E-angelo]

Well that's the thing, @mrlacey ... what is "ubiquitous"? WPF clearly has waaaaaaaaaaaaaaaaaay more installs than both UWP and XF combined, and is clearly a "ubiquitous" Xaml technology, but best I can tell is presently not being considered as a tech that the Standard is recognizing. It is true that for every install of UWP, you have WPF along for the ride. So in that regard, UWP is 1-to-1 with WPF. But then you have all the dark matter installs which account for 100s of millions of Windows XP (yep, still around), Vista, and the Almighty Windows 7.

Sort of a problem, methinks. I for one would really like to see how Xaml installs and usage are counted and acknowledged within the Standard. It is astonishing that a tech with 100s of millions of installs is simply being disregarded -- or at the very least appears to be disregarded as I have yet to see anything that says otherwise.

(Apologies for going OT... maybe this should be in another thread, but thought I would mention it real quick-like. 🏃)

[birbilis]

btw, with WPF one would usually use MediaPlayer control (probably Windows Media Player ActiveX internally), but MS could have ported SMF/MMPPF to WPF (would also need to release Smooth Streaming Client SDK for WPF). That was a really mature framework, even available for Xbox (and don't mean via UWP, but via some kind of Silverlight API for Xbox). Recent versions also support HLS and think they support DASH too (which is similar to Smooth Streaming after all)

[birbilis]

maybe somebody should archive the patches contributed by 3rd party devs to such repos now that codeplex is closing down and will become readonly. I'm afraid such (many times useful) patches that hadn't been accepted/merged will be lost in the process

[mrlacey]

@Mike-EEE by "ubiquitous" I was referring to the principle as per the link in my post. As has been stated many times in announcements and Build sessions about XAML Standard, the purpose with version 1.0 is to address the disparity between common controls that exist across platforms. For XS1.0 that means UWP and Xamarin.Forms. Its purpose is not to define new controls.

From that link:

For XAML Standard 1.0 - the primary goal is to unify the dialects between UWP and Xamarin.Forms.

I believe that future support for WPF within the standard has been discussed, and will be discussed further. But obviously beyond the scope of v1.0.

The principle referring to ubiquitous APIs isn't about installs, it's about the commonality between different flavors of XAML.
The standard is about moving forward and Microsoft has stated that this means a greater focus on UWP than WPF as UWP has been specifically designed to work with the numerous and varied and different computing devices of the future.

Yes, a separate issue is the place to discuss this. It's issue #20. Hijacking threads to talk about something unrelated is spammy, unhelpful and doesn't serve the goal of the project.

[insinfo]

When proposing the creation of a new open standard of a markup language for the creation of graphical interfaces, it is logical to assume that there will be proposals for new parameters, resources, reserved words, interface controls among other things. And there will be a lot of implementation work by those who want to support compatibility with this new standard. Therefore, it is the place and opportunity for developers to indicate the controls or features they want in the specification and that logically consequently enter into APIs that want compatibility with this new standard. If it's just to combine Xamarin.Forms with UWP, then it's not a new open standard and it does not need the community to do this, or we're wasting our time here then.

[dotMorten]

I'm afraid this is going a bit off topic, but I just want to address this:

If it's just to combine Xamarin.Forms with UWP, then it's not a new standard

First to quote the documentation from the repo which I encourage you to read:

For XAML Standard 1.0 - the primary goal is to unify the dialects between UWP and Xamarin.Forms.

Second, why would this not make it new and a standard? It's definitely a 'new' standard, because no such standard exists today, and UWP and XF are quite different XAML flavors.

Having said that, that is stated as the current goal for v1.0. It does not state what the goal is for v.next, and I don't see why adding new common controls that makes sense on all platforms to be defined there.

You do however have to consider that UWP, Android and iOS are very different UI/UX wise, so IMHO it's dangerous to include too many UI specific concepts in the common parts of the standard. It's also worth keeping in mind that XAML Standard is merely a common subset of what each platform defines. Just because the standard doesn't have a specific property, doesn't mean a platform can't add it, if it makes sense on that platform.

I'm my opinion it's more important to define the names and properties a set of basic controls that are in fact the same, and focus on the base-building blocks of UI, like Grid, StackPanel, ItemsControl, TextBlock, Button etc. In addition to that, we should have a common set of concepts defined like Binding, VisualState, Storyboard, Attached Properties, Event triggers/commanding etc. @Insinfo has proposed a HUGE set of different controls - most of which I think fall completely out of the XAML standard category, because they are so incredible specific that they will either be unusable for each scenario, or too complex to really use (that doesn't necessarily apply to MediaElement), and really fit much better into a 3rd party library (which would be easier to build since they now have a standard to get some commonality across the platforms)

[insinfo]

Currently all platforms support video playback in some way, so this "MidiaElement" control can be minimally aligned between platforms. I believe this control is very important for a robust and complete XAML standard, and for modern next-generation software that involves visual programming, interactivity with neural networks, and more.

[birbilis]

SMF - Silverlight Media Framework (now called MMPPF - God knows what they were thinking when naming it) is what is needed for more serious work with video and streaming (HLS, Smooth Streaming, DASH), captioning (for accessibility, education etc. uses) etc.

That one builds on top of some IIS library that builds on top of MediaElement if I remember well. Ideally I'd love to see some concepts from it in the XAML standard, or make sure that the base player has extensibility so that MMPPF can be build upon it and be portable to more platforms

[insinfo]

@birbilis

make sure that the base player has extensibility so that MMPPF can be build upon it and be portable to more platforms

I fully agree with you