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 LIF1SIDIRSeq. #BBPSDASM Rule 32Timestamp 64Reliable 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

Bits0 – 78 – 1516 – 2324 – 31 0Source portDestination port 32Verification tag 64Checksum 96Chunk 1 typeChunk 1 flagsChunk 1 length 128Chunk 1 data …… …Chunk N typeChunk N flagsChunk 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 StreamingProgressive 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 files Example: 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 conferencing Goals:  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!