Video streaming (where streaming means that someone is producing data , and someone else is consuming it) generally follows these two approaches based on the "subscription" type:
- Push model of viewing data - e.g. i "subscribe" for a newspaper, and the newspaper is "pushed" to my house. Similarly, if clients subscribe to some multicast addresses, servers will push data to multicast addresses using UDP (or RTP). Client-server is unicast, but server-client is SSM or ASM. These days apparently one can do multicast on RTMP.
- Pull model of viewing data - e.g. go to a newspaper stand to buy newspapers, i.e. no pre-decided "subscription". Clients will ask for chunks (i.e. ask the server to transmit the chunk) of data from server using HTTP, RTSP, other signaling mechanisms (e.g. RTCP) i.e. one is a streaming channel, and one control channel. These are unicast messages both ways. Note that the "chunk" here may be the entire size of the video file. If one wants to do "adaptive" rate control streaming, then one may have smaller chunks and ask more chunks as deemed necessary.
IPTV on the other hand could be described as using the push model, where clients just ask for the data transmission to start (via IGMP join or via RTSP) , and the server then pushes data to the multicast.
I am not sure if RTMP is a push or a pull model. I am guessing it is a push model.
Cisco Videoscape/Apple TV/Google TV/:
Cisco Videoscape,
Apple TV,
Google Tv is the merging of TV and internet.
Today, "television" (unlike internet video) has been a
'real-time' system i.e. content is buffered for a small jitter-buffer (maybe a few seconds max.) & attempted to be repaired, but IF it happens so that there are gaps in the content, today, one sees the occasional screen-jitter i.e. today, TV content on screen is not frozen with a "buffering..." thing.
Thus, if one wants to provide a TV-like experience, one would have to create UDP streaming APIs (or loss-tolerant-TCP which is in other words:
TCP Friendly UDP). Of course, this means that
VQE like solutions can still be useful for these applications. Of course, this is just one way -- the other and probably the more attractive method is to use Adaptive Bitrate Streaming (ABR), and TCP, and a pull mechanism based on chunks of the video.
RTSP:
Originally developed as a 'remote control' mechanism, and is a "stateful" protocol. Client has 4 states (init, ready, playing, recording) and server has 4 states too (init, ready, playing, recording).
This was a good intro.
HTTP/RTMP/MMS are also used for signaling
Transport protocols:
HTTP (over TCP, rarely UDP), RTP/RTCP over UDP (rarely over TCP), RTMP (/optionally over HTTP) using TCP/UDP, MMS
Anyway
this was a nice link comparing the different streaming protocols and their features.
Overview of Adobe Streaming tech
Actionscript vs. Javascript:
http://answers.yahoo.com/question/index?qid=20081212142558AAluL6n
SWF vs. FLV:
while we are on this topic, it is useful to know the difference between a SWF(player/metadata) and a FLV(data) (see
this). This is a somewhat basic beginner kind of a question.
Here is a link to see how Flash Video is distributed
RTMP:
Note that just by using SWF and FLV over HTTP video streaming can be achieved - what we call as "progressive download" of the FLV.
Adobe created another solution for streaming called RTMP.
RTMP is used to talk from the player (running in the browser) with the server, and eventually send the FLV video with a difference that the client can jump to any location.
Youtube does use RTMP for storing video using RTMPT (see
this). However, while streaming, Youtube used chunked HTTP transfers,
Apple Streaming tech:
HLS
