Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×

Comment: Re:And now, things get Ugly. (Score 2) 120

by martin-boundary (#49334657) Attached to: Uber To Turn Into a Big Data Company By Selling Location Data
No, he's not. He's a bystander in the deal between Uber and the advertisers. As a bystander, he can do whatever he wants. If he decides to shit all over the data Uber intend to sell the advertisers, that's fine. If he decides to sue the advertisers for wrongful access to his data, that's fine. If he decides to sue Uber for privacy violations, that's fine too. Basically, the sky's the limit, since Uber are illegally misusing his data (at least in the EU - where companies are only allowed to use personal data for the immediate business at hand - meaning getting you from A to B in the case of Uber).

So go ahead, make Uber's day.

Comment: Re:ummm... (Score 1) 81

by martin-boundary (#49058587) Attached to: The Revolution Wasn't Televised: the Early Days of YouTube

Uh, no, that's the hint that you need. It's irrelevant what happens in the CDN.

It's actually far from irrelevant. The CDN is the major reason "streaming" services are viable in the first place. Without the CDNs we'd be back in the real streaming era of RealPlayer et al, right before that small company Akamai saw a business opportunity...

You're still going to stream it to your player.

Nope. Your player reads it from a growing file on disk. If you only want to concentrate on that part and call it streaming, then you've already lost the whole transporting across the network part, including controlling what gets streamed while it happens.

If it starts playing before you finish downloading, you're streaming.

Still incorrect. That's just playing a partially completed file on disk. It's "streaming" in the most primitive way possible. For example, you can't seek forward and play another part of the media until you've waited for the full file up to that point to be downloaded. True media streaming technologies allow the player to seek forward, *and not get the bits in between*. Basically, the server doesn't send any unnecessary bits, modulo the encoding method.

In your "disk as the media server" analogy, you would want to have some way to access the file randomly - that's only possible when the intermediate data has already been stored.

If you have to wait for the whole file to download before you can watch, then it's not streaming.

There you go. We seem to be in agreement after all. If you have to wait for 90% of the whole file to be downloaded before you can seek to the 90% position, then it's not streaming.

There probably are still video services like that, but I don't know of any.

There's an easy test you can perform to find out: stream a large file (large enough to take some time to download) and right at the start, have your player seek to somewhere near the end. If it starts playing the end straight away, it's probably a streming player, but if you have to wait a while, then it's probably a downloading player.

Whether the video gets downloaded into a buffer in memory or a buffer in a disk file is completely irrelevant to the question of whether you are streaming. It only speaks to the issue of how it is done.

Not so. I argue that the difference in technology is sufficiently important to the end user experience that without downloading tech, streaming media business models wouldn't have taken off - as they didn't in the early days when this was tried.

Ultimately, my point is that "streaming" as some of you use the word is a marketing term, useful to give the impression that data arrives on demand into the player and disappears as soon as it has been used, whereas this isn't the reality. True streaming like that is certainly possible and there are servers that do it, but mostly it's downloading files and hiding them. And I happen to like finding them and maybe processing them in ways that work for me.

Comment: Re:ummm... (Score 1) 81

by martin-boundary (#49057617) Attached to: The Revolution Wasn't Televised: the Early Days of YouTube
No, streaming refers to data being sent on demand without store-and-forward. For video, it means your server broadcasts UDP packets which your player reads. If the player elects to save the packets in a buffer and delay playing them, that's still streaming. If the player accesses a file on disk, which was independently downloaded using a standard file transfer protocol, that's downloading - even if the player starts showing the data after a short time before the file is fully downloaed.

The distinction is important - streaming is an end-to-end communication directly over the network, whereas downloading can and often does involve middlemen - eg CDNs, proxies, etc. The technology stack for downloading is way more elaborate, advanced and versatile than the technology stack for streaming. The advantage of the latter is that the data is realtime, not delayed.

People will buy anything that's one to a customer.

Working...