Daniel Johnson

Playing a media file stored on a remote server on a local client

iTunes “Shared Libraries”

Google Video, youTube, etc.

True Streaming

Progressive Streaming or Pseudo-streaming

Benefits Counter piracy

Files stay on the server No need for DRM

You can start playing anywhere in the file

Costs Expensive

Requires a “streaming server” Poor quality

Delay Jitter Low resolution

Protocols RTP – Real-time Transport Protocol RTCP - Real-time Transport Control Protocol RTSP – Real-Time Streaming Protocol(All of the above come in a Secure variety) RDT – Real Data Transport

(proprietary – Real Networks) DAAP – Digital Audio Access Protocol

(proprietary – Apple Inc.) SCTP – Stream Control Transport Protocol

“Control” is a bit of a misnomer: Doesn’t actually control the stream Used to gather data about the RTP stream

bytes sent packets sent lost packets Jitter Feedback Round trip delay

Data can be used by apps to control flow and achieve a better, more consistent stream

Similar to HTTP, but with modified/additional commands to facilitate streaming media

Built to be Transport layer independent: TCP UDP SCTP RTP (most common)

Header is similar to HTTP/1.1

Bits 0 1 2-6 7 8-16 17-23 24 25 26-31

0 LIF 1 SID IR Seq. # BBP SD ASM Rule

32 Timestamp

64 Reliable Seq. # Data

Most widely used true streaming protocol because of the popularity of iTunes

Created by Apple as a proprietary protocol – introduced with iTunes 4

Reverse engineered and became open source

Apple reasserts ownership with v. 7 Poorly documented

Referred to as “multi-streaming” Based on the PSTN message delivery

concept Allows multiple source and destination

hosts Keeps much of the reliability of TCP,

without the restrictions because it’s basic unit is a full message instead of a byte

Bits 0 – 7 8 – 15 16 – 23 24 – 31

0 Source port Destination port

32 Verification tag

64 Checksum

96 Chunk 1 type Chunk 1 flags Chunk 1 length

128 Chunk 1 data

… …

… Chunk N type Chunk N flags Chunk N length

… Chunk N data

Benefits Cheap Built on existing internet technology

Uses standard web server No new protocol implementations required

Much better quality (potentially)

Costs File must be downloaded to client HDD (easy

to pirate) Can’t (technically) navigate file

Uses HTTP (sometimes FTP) to send file to client HDD

Most clients begin playing the file before the get all of it Speeds up playback If there’s a problem, playback stops

completely Speed is determined by total size of file

Better quality requires waiting longer, and visa versa

True Streaming Progressive Streaming

Expensive – requires a special server

Fast Controllable Protected

Cheap – don’t need anything new

Slow(er) Must start from the

beginning Open

iTunes “Shared Libraries”

Google Video, youTube, etc.

The right compression (codecs)

The right resolution

Not all codecs work for streaming Streaming codecs should allow

high compression playback of incomplete filesExample: MPEG-1

Originally video decoding was done with special hardware based on TV decoding Rectangular pixels Cropped the sides

Result was an optimal resolution of 352x240

Software decoders didn’t bother with this

The Result

The other predominant influence on internet video was video conferencingGoals: conserve bandwidth Still look good

The result was settling on 176x144 Most software decoders don’t worry

about this either

The Result

Most software decoders ignore the “format” flag in the encoding

A lot of encoders had either the TV format or the video conferencing format as their default resolution (this has mostly been corrected)

Lots of videos made early on were stretched or squished

I do not like it on ABC,I do not like it on MTV. I would not, could not on CNN, I would not, could not on ESPN. It can't be 176x144, Bill G. Because then it isn't 4:3!*

Use a 4:3 Aspect ratio for you web videos!