Before flash could play video, links that open in the media player of your choice were very common.
It was a nightmare. Each media player would try to hijack every link type it knew about each time it ran. But there wasn't full compatibility. So you'd click a link, RealPlayer would try to open it, and the player would crash.
The major players actively fought open standards, because they each had dreams of controlling a DRM & patent gated empire.
Flash brought some sanity to web video. Although initially it had performance issues (it had issues with hardware overlays on some video hardware).
I wouldn't say "initially"; Flash is still notorious for severe performance issues. That said, so are most native media players nowadays.
With that said, I'd be more optimistic of a kind of "media plugin renaissance" like what's being discussed in this day and age than I would be back in the 90's, what with all the insistence on standards-compliance and all that jazz. Eventually, with platforms like the .NET CLR / Mono catching on and becoming increasingly popular for cross-platform "native" (not quite native, but much more native than web-based) development, the chance of successfully reaching the goal that Java tried (and - arguably - failed) to reach back in the 90's is much higher nowadays.
I'm a bit less optimistic. Having different programs for each content type would restrict the developers' control into how they can interact with the users.
Simple playback of video? Not so bad. But if you want to swap the source of the video to your 240p version if the video is buffering 'too slowly'? YouTube-like annotations? Show suggested videos after? Developers aren't going to want to support all environment configurations, so you'd likely end up with a separate supported player for each website.. which doesn't sound better than visiting a webapp tested against the popular web browsers.
Additionally, there's a lot of great research going into browser sandboxing and user-driven permission granting. Allowing content-compatible-but-unsandboxed XYZPlayer to take over content playback negates a lot of the potential benefits.
> But if you want to swap the source of the video to your 240p version if the video is buffering 'too slowly'?
This sounds like something that should be a feature of the protocol used for streaming (in fact, I'd be surprised if most streaming protocols didn't support such functionality). Even without, this should be possible to do even with a native media player, and many streaming providers offer streams with different bitrates and encodings and such (for an example, check out soma.fm).
> YouTube-like annotations?
Most video players have subtitle and even captioning support; it shouldn't be hard to extend this to arbitrary annotations, be it as part of the streaming protocol, part of the media encoding, or even as a separate stream or file.
> Show suggested videos after?
Could be hypothetically done with an API call on the player's part to the video source (or some other source that indexes videos), which then provides the list. The player could then display said suggestions.
All three of these things could be worked around with a standard "metadata" path that such a video player would access and fetch an HTML page or JSON/XML document or somesuch.
> Developers aren't going to want to support all environment configurations
Nor should they; they should instead support agreed-upon standards, like how web browsers support agreed-upon standards for HTML/CSS/Javascript files and HTTP(S) 1.x/2.0. I don't use separate web browsers for different websites, after all.
> Additionally, there's a lot of great research going into browser sandboxing and user-driven permission granting. Allowing content-compatible-but-unsandboxed XYZPlayer to take over content playback negates a lot of the potential benefits.
Part of the issue is that operating-system-level sandboxing has historically been insufficient. Bringing some modern server-grade sandboxing techniques (containers, VMs, chroots, etc.) to the desktop and mobile realms in an easy-to-use manner would alleviate the need for browsers to try and implement this themselves.
I agree that those are all methods of solving each issue -- but I think expecting each player to implement them (and correctly!) is the real problem. And when the standards don't support the feature they want, many developers would fall back to the web. It's hard to compete with a full-featured layout, style, and scripting implementation when it comes to customization.
Nor should they; they should instead support agreed-upon standards, like how web browsers support agreed-upon standards for HTML/CSS/Javascript files and HTTP(S) 1.x/2.0.
There are web standards now, but, in practice, when you're supporting multiple environments, you're also testing against them. For webapps, fortunately, this usually just entails testing the top 5 browsers for a few versions, and mobile devices if you support them.
If the user comes to support saying something is broken with the video on their native app, trying to troubleshoot their native environment can be difficult, and telling them that their environment might be configured wrong often doesn't solve their problem. Which is why I suspect each site would support specific players.. not being a real improvement over the Gecko or WebKit <video>, <audio> in my mind..
Netscape could do this back in 1995. One of its preference settings let you associate external applications with certain MIME types; when you clicked on a link pointing to a resource of that type, it would automatically open the external program to view the file, as if you had double-clicked on it.
Similarly, you can do this right now on Android. When you click on a link, it fires off an Intent with the URL. Apps can register for this Intent and the user will be prompted for what program they wish to handle the link in. This is how the official YouTube/Google Maps/G+ apps work.
It turns out that for certain types of content, users really, really don't like to wait for external programs to load. It's not a technology issue; the technology has long existed to use rich clients, consumers just don't prefer it.
> It turns out that for certain types of content, users really, really don't like to wait for external programs to load.
And yet they click through full page ads, wait for "loading showcase" animations, scroll past parallax scrolling banner images and also wait for the ads on youtube videos and for the video to switch from 360p to HD.
Users are strange creatures.
I think if some effort were put into streamlining the native <-> web boundary then users would be quite happy with it.
> This is how the official YouTube/Google Maps/G+ apps work.
The question is, could this be standardized further? Basically a web standard that browsers agree to when it comes to talking to native apps that might offer specific services.
At the risk of getting stoned to death for this: WebD-Bus?
Although I think anything like that isn't going to happen. Browser vendors put security over everything else. Talking to native apps which already have access to the system would probably be construed as some sort of security risk, even if the user had to opt-in.
Ads exist in Native apps as well. At least in the web I have the option of browser extensions to provide a more customizable UX. With adBlock I don't get Youtube ads on Chrome so that point is null.
As for the last point, Spotify has some version of this. My native (mobile) Spotify app knows when I'm playing on my computer and vice-versa.
>It turns out that for certain types of content, users really, really don't like to wait for external programs to load.
I'm not sure how that's a valid point. My native media player loads in literally less than a second. (I timed it at 0.59s from when I double-click a file and it starts playback.) This is faster than any webpage can ever dream of loading. And unlike Flash or HTML5 video it gives me completely hitch free playback, whereas browser integrated player tend to drop frames quite frequently.
I would much rather use it than any player integrated into a web browser.
It wouldn't be hard to make that work on other sites that have a flash player. But we aren't quite sure if it improved the performance or anything, it just felt right.
This is an issue with the service not providing direct links to the video.
If you open an .mp4 file in Firefox you can set it to open in an application through your "Applications" settings. By default it prompts "Open with..." or "Save as..." in a dialogue.
If you open a direct link to a video you can open it to play in VLC (or player of your choice).
Some (most?) browsers still do this when presented with a media file. Firefox in particular will use VLC on my machine for that purpose (or, if it's not installed, some HTML5 barebones media player, or some other media player that can be embedded if one is installed).
If I could stream directly to VLC or a player of my choice I'd be happy with that.