how about http://some.storage.service.tld/path/to/video.mkv or even rtmp://some.streaming.service.tld/path/to/stream ?

For sharing that would be sufficient.

Of course there are some business realities (ads, copyright, paying for storage) that make direct, free access to videos unlikely. But that's basically arguing that the web is a superior platform for monetizing things, not necessarily a superior platform as far as user-experience goes.

> The other key piece is discoverability, and on that front, YouTube is far, far better

I'll give you that one.

But then again there are dedicated media-discovery-sites (imdb, last.fm) that do not have playback as their core functionality, even though they may offer some playback.

Raw streaming urls don't get me any of that. URLs aren't just pointers to bytestreams. From a user sharing perspective, they're humans pointing to a unique thing. And what they're pointing to is often much more complex than a single raw file.

    https://mytube.com/$username/my_first_video.ogg

Sure, now the user would have to go through the additional work of editing URLs if they want to access this endpoint manually, but then this article's points come into play: if your users expect more functionality than what the World Wide Web does well - delivering content - then a native app is probably preferable for everyone involved (and, indeed, exists for sites like YouTube).

They're asking: what person or persons did this, what might I know them for, what do they look like, how popular are they, do they have a logo I might recognize? YouTube and Vimeo provide that information right next to the video, which is where people want it.

If a native app really is preferable, then I'm sure we'll see YouTube wind down their web interface once everybody stops using it. But my guess is that they'll still have an HTML version long after you and I are both in the ground.

And even with the URL alone, that's still significantly less opaque than YouTube's current method of https://youtube.com/$some_random_gibberish. At least someone could see something like https://mytube.com/j_random_hacker/how_to_computer.mp4 and guess that "j_random_hacker" is a username and "how_to_computer.mp4" is a video uploaded by that user.

This isn't much different from, say, reddit, where URLs are actually part of normal discussion; a redditor will talk about a subreddit called "/r/mylittlepony" or a user named "/u/Unidan" or somesuch, directly referencing paths (to https:/reddit.com/r/mylittlepony and https://reddit.com/u/Unidan, respectively). Granted, reddit's userbase is somewhat more tech-savvy on average than, say, Facebook's or YouTube's, but it shows that URLs are not necessarily opaque to typical users, and it's certainly not hard to even manually demonstrate such things to new users.

This also isn't much different from many (most?) news sites, which provide URLs that resemble the name of the article (with some adjustment to make everything lowercase, turn spaces into underscores, strip or substitute special characters, etc.).

Like a web browser?

There's no reason why a native app can't do this - in fact, many native apps for things like YouTube and Pandora and such already do this.

you want to share youtube comments with people? they are a significant value-add to you?

And here I'd concluded the comments section existed to allow pre-teens to practice their ability to make racist remarks.

No, it is not. Playback would get stuck, sound would go away for no rhyme or reason and what not. Better experience? - no - quite the opposite.

I got rid [1] of the native nuisance completely. And the experience of search, comment and history on native was simply terrible. Much lesser control on ad-blocking too, and really the ads on YT are sometimes seriously irritating.

[1] Evidence: https://twitter.com/marvindanig/status/598701509963083777

Evidence: ^

And yet it's existed for years using p2p/torrents. So they're more like business fictions

Well said, you should tell this to Disney, MPAA, and MAFIAA so they'll stop trampling the rights of the commons by extending the length of copyrights everytime something profitable to them is about to expire. https://en.wikipedia.org/wiki/Copyright_Term_Extension_Act

The "4th option" is that you've got the causality completely backwards in your head: it just happens to be the case that the cultures where distributed tooling became important were the ones where it was necessary to promote an "all information is free" mindset, not that it's necessarily a part of distributed tooling that you take that mindset.

If we start with a centralized metadata server/peer tracker, a set of "base seeds" to keep videos alive, and a commenting system, we can still revoke access to individual videos (our app will simply not support peer discovery except through our tracker, we take down the seeds, comments, and tracker entry on a revocation) while distributing bandwidth for the viral videos that need it.

The point is germane.

Not at all, YT solved it many years ago with ContentID.

Now imagine having to install all the plethora of apps on every device, one for videos, one for music, 500 for different types of documents, etc. Instead, you install a (hopefully) standard-compliant browser, and done.

Sorry, there is some ambiguity in English about this. I am regarding a "solved problem" as a "problem" (i.e. classification) whereas you are regarding it as "no longer a problem" (i.e. interface). Yes, right now YouTube's interaction with the problem is highly limited (though not nonexistent), but if one is, say, trying to disrupt YouTube or talk about YouTube's history, one still classifies it as a problem in general that exists within YouTube's problem domain.

> Now imagine having to install all the plethora of apps on every device, one for videos, one for music, 500 for different types of documents, etc. Instead, you install a (hopefully) standard-compliant browser, and done.

I mean, I agree that it helps that particular problem somewhat to have a cross-platform virtual machine (the browser) and to distribute an executable (your JS app) on that machine rather than (or sometimes alongside) your content. This also creates its own problems, of course, like simpler browsers (spiders, text-only browsers) not being compatible with your website, as well as some new buggy issues when, say, the JS doesn't load properly. But HTML+CSS+JS is not new in this town and the cemetery has some gravestones -- like the fact that there aren't many desktop Java applications, the complete failure of the Java browser plugin, and the waning of the Flash plugin. It is peculiar among these only because its dreams are less lofty: not "write once run everywhere" but "write once, then write a (hopefully graceful) downgrade path if they do not support the features that I want to use."

I'm not sure I understand. AFAIK youtube currently makes money (from ads) and much of what people view is copyrighted music that isn't properly licensed, and which yt doesn't pay for.

Sure, some, music is taken off yt, and some content is properly licensed -- but are you seriously claiming that yt isn't (any more) making money from copyright infringement?

There's some digital content distributed via p2p legally -- and it'd not be a stretch that yt owes it's current market dominance to "flaunting copyright law" as the copyright lobby might put it.

If one relegated content (video, meta-data, comments) to torrents/magnet-links (there is an issue of loops in the links in content-addressed systems -- but with a pretty modest central server (cluster) serving up a few lists of magnet-links should be affordable)) -- I think it would be quite feasible to distribute digital media in way which the consumers shared in the meagre cost of distribution through mostly donating bandwidth.

Synchronized play state and playlists on all the devices. Offline handling of the media files with streaming as an option. Feed subscription but also podcast repository and ranking/trending screens.

All media files are by definition in independant feeds, and sharing a file URL is supported.

It brings a hugely better experience than youtube pr any online video service I've seen. I actually switched to my podcast player all the youtube channels that also have a separate feed.

I'm always baffled by the suggestions when watching videos from some common series. There would be mostly accurate suggestions, and consistently two or three videos completely unrelated taken from my viewing history. For instance there would be 'Howto repair your dishwasher' in the middle of all the videos of a math channel.

I tend to massively subscribe to channels and watch in batches, so I have (and want to have) a very good idea of what's coming next in my queue.

If I could stream directly to VLC or a player of my choice I'd be happy with that.

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

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.

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.

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.

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

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.

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.

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.

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.

https://www.reddit.com/r/WatchPeopleCode/comments/3273es/pro...

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.

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

http://en.wikipedia.org/wiki/Google_Videos#Google_Video_Play...

The same disappointment hit me with the early releases of Chrome browser - just Firefox with stuff removed.

I seem to remember being able to do that two decades ago. I imagine you still can (assuming you're up-to-speed with the configuration UI of the week for your browser), but it's not something people seem to do a lot.

What about URLs mean that a native player can't use them?

The only reason youtube is better on that front is because google.

Related to that, if you try to scrub to a position BEFORE what you are watching right now (say, 1 minute before), which is obviously buffered since you have just watched it, it goes full loading-retard again. It's like it just throws away the data it buffered and showed you. It is insanely infuriating.

https://rpetri.ch/cydia/videopane/

Do you report these? It's been ages since I saw a PDF that pdf.js misrendered.

This is what I use instead: mplayer -fixed-vo $( youtube-dl -gf mp4 $* "$link" )

If you have the HTML player enabled, and if your GPU supports hardware H.264 decoding (most do these days), this plugin may help:

https://github.com/erkserkserks/h264ify

Otherwise Youtube might send VP8, which your CPU has to decode.

And at it's core, BetMax is better than VHS. HD-DVD is better than Blu-Ray.

Often, it's not about what is "better". It's about who has the most moment, is easier, less encumbered by DRM, etc.

Sometimes it's better to download Youtube... more often than not, Youtube "just works".

Actually this is exact reverse of a Betamax story - better and more expensive long term improvement won over short term and cheaper one.

Remember, on the web, you are the product.

The same goes for many other things:

- Movie theatres in the last few years (commercials before movies)

- Television since the days of black-and-white TVs.

- Radio dramas "sponsored by X" before TVs existed.

How has anything changed?

I would argue YouTube's core functionality is "making it easy to share videos with family, friends, and the world". Allowing playback of the videos on the page makes this functionality easier.

>Often I find myself using youtube-dl to fetch a youtube video and just play it in a regular media player because it just works better than what browsers have to offer.

I do this too - although only because an addon I have causes Firefox to memleak if I leave a YouTube tab open too long. Rather than finding the problem and fixing it - I download a video I want to watch and close the YouTube tab. Honestly my video player of choice (MPC-HC) does exactly what the YouTube player does. It plays the video. Not a whole lot of bells and whistles needed to do that.

Examples of this hampering is that they only stream 20sec ahead instead of the whole clip in one shot. There are many other annoyances like this, like not giving you the HD version even though it says the video is HD and you've selected HD, or when it re-streams the movie when you switch from windowed to fullscreen, probably because the windowed version was too low quality.

That's it exactly. The author claims it's an unsolved problem, I think it's the inevitable solution (that web and native will merge).

web and native will eventually merge to the point that for most intents and purposes the user can't distinguish between them. It'll never be perfect, but it'll be "good enough", that whether an app comes from the web or from the HD, the user won't really notice except perhaps in the initial startup time, and probably not even then (everyone expects to "install" an app).

But can you build a democratic 24/7 music/video feed with a native video playback app? Maybe, but it is much easier with the web. And it has already been done:

http://botwillacceptanything.com:3000/video

https://github.com/botwillacceptanything/botwillacceptanythi...

I invite anyone with the time and inclination to submit a pull request that changes the content of the video feed.

That isn't its core functionally, it's a social video sharing site, not a video playback site. It's core functionality is social sharing and all that goes with that, comments, related videos, channels, etc.