1. Daniel Johnson

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

4.  iTunes “Shared Libraries”  Google Video, youTube, etc.

6.  True Streaming  Progressive Streaming or Pseudo-streaming

7.  Benefits  Counter piracy  Files stay on the server  No need for DRM  You can start playing anywhere in the file

8.  Costs  Expensive  Requires a “streaming server”  Poor quality  Delay  Jitter  Low resolution

9.  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

11. “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

12.  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

13. Bits012-678-1617-23242526-31 0 LIF1SIDIRSeq. #BBPSDASM Rule 32Timestamp 64Reliable Seq. #Data

14.  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

15.  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

16. 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

17.  Benefits  Cheap  Built on existing internet technology  Uses standard web server  No new protocol implementations required  Much better quality (potentially)

18.  Costs  File must be downloaded to client HDD (easy to pirate)  Can’t (technically) navigate file

19.  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

20. 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

21.  iTunes “Shared Libraries”  Google Video, youTube, etc.

23.  The right compression (codecs)  The right resolution

24.  Not all codecs work for streaming  Streaming codecs should allow  high compression  playback of incomplete files Example: MPEG-1

26.  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

27. The Result

28.  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

29. The Result

30.  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

31. 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!