[linux-elitists] Streaming patent claims go to court

john spurling synec@nakedlunch.org
Sun Feb 16 07:56:12 PST 2003


On Sun, Feb 16, 2003 at 11:31:05AM -0500, Modus Operandi wrote:
> billy@damaged-world.net looked into the void, and said:
> 
> > Could someone please explain to me the fundamental difference
> > between "streaming" a file, and downloading it? 

most generally, "streaming" means that the data is sent as a live,
continuous stream of data, much akin to a television
broadcast. contrast this with a file download, where you care much
less about the timing and more about the entire file getting to the
destination intact. while perfect data replication may sound like a
desireable goal all the time, in the case of streaming, it isn't,
because if you drop a single packet in a media stream (which would
hardly be noticeable to the user), you don't want the stream to jump
back several seconds.

most typically, this means that downloading is implemented using tcp,
where you're guaranteed to get the data in order, intact, and all that
other happy stuff, and streaming is usually implemented with udp, with
some media timestamp information added to the protocol stream using
(usually) rtp.


>   Non-technical answer:
> 
>   Streaming media is played as it arrives in a continuous data
>   stream from a remote server. The alternative is a recording
>   that doesn't start playing until the entire file has arrived.

this is often not true. witness quicktime's browser plugin, which
always (afaik) does download via http. it will start playing when a
certain amount of the file has come in.

>   This has its pros and cons. If your goal is to watch several 
>   hours of FCC roundtables on ownership restrictions:
> 
>   	http://www.fcc.gov/realaudio/
> 
>   streaming video is the way to go, because you don't want to
>   wait for the entire file to download before you start
>   watching. On the other hand, streaming media is used for
>   digital rights management, since you do not actually download
>   the content -- only a link to the remote location of the data
>   stream. So if you download a file, you can play it over and
>   over again without any more network traffic. This is not the
>   case with streams -- the proprietary content is never stored
>   on your hard drive, you only keep a link to a remotely-hosted
>   stream of the content -- so you can't copy it or host it on
>   your website without intercepting the output from the stream
>   and reencoding it as a new file. This also prevents people
>   from mirroring the content -- so when the multi-cast ends, the
>   stream is gone and the link doesn't work anymore.

typically streaming media applications don't let you save the stream
to disk, but a few do. although streaming has been used for trivial
drm, it dissuades all but the most non-technical from "ripping" a
stream to disk. various stream ripping applications exist, even for
streaming platforms that use non-standard streaming protocols.

-john



More information about the linux-elitists mailing list