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

+ Bits

0 32 64 96 96+(CC×32)

0-1 2 3 4-7 8 9-15 16-31

Ver. P X CC M PT Timestamp Sequence Number SSRC identifier ... CSRC identifiers ...

Additional header (optional), indicates length "AHL" 96+(CC×32) + (X×(AHL+16)) Data

“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 32 64

0 1 2-6

LIF 1 SID

7

IR Reliable Seq. #

8-16 17-23 24 25 26-31

Seq. # Timestamp BBP SD ASM Rule 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 32 64 96 128 … … …

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

Source port Destination port Verification tag Checksum Chunk 1 type Chunk 1 flags Chunk 1 data Chunk 1 length Chunk N type Chunk N flags … Chunk N data Chunk N length

 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     Expensive – requires a special server Fast Controllable Protected Progressive Streaming     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!