Streaming Media Unicast Redundant trafficPresentation Transcript
One to many
multicast enabled network
Real-time Requirements Support
QoS and Resource reservation
Resource Reservation to bound data
delivery delay, loss, jitter etc.
Adaptive Rate Control
Adjust video traffic characteristics to suit
Periodic generation of frames at regular
Variable bit rate.
Frame periodicity must be maintained
for the video to appear “smooth”
Data unavailable at playout is useless.
Jitter (variability in interarrival times)
Buffering and Start-up Latency
Congestion leads to Data Loss
Decreasing Data Rate
Delay Sensitive, Loss Insensitive
Multicast and Heterogeneity
The Internet is Heterogeneous
Traffic density (Temporal)
Every receiver should receive video that is
commensurate to the resources available.
Is this fair to “other” traffic?
Rate Adaptive Digital Video
Compression, Scene Complexity, Motion
Raw video stream is fed to encoder
Encoder sends encoded data to buffer
Buffer level provides feedback
Feedback is used to control data output
rate at encoder.
Quantization, frame rate, pixel
resolution etc. are controlled.
Network feedback can also be used.
Queueing information (internal to the
Adaptive Bit-Rate Video
Single Stream Adaptive Approach
Replicated Streams Adaptive Approach
Layered Video Streams Approach
Real-Time Transport Protocol
NO notion of “Connection”. (hence
Requires framing and segmentation be
taken care of by lower layers.
Divided into two parts (consecutive
ports for UDP)
Data (audio + video packets, even-
Can use single PDU in case UDP is not
Real-time Transport Protocol
RTP Data Packets
12 byte header
can be encapsulated in encoding-specific
RTP Data Packet Header
Payload Type (1 byte)
eg: JPEG etc.
Timestamp (32 bits)
generation instant of the data
Sequence marker (16 bits)
packet seq. number to help loss detection
end of frame for video
beginning of talk-spurt for audio
RTP Control Channel
Control protocol called RTCP
QoS monitoring and Congestion Control
all other receivers know how others are doing
sender-report, helps receivers compute data-rate
wall-clock time + RTP timestamp
allows synch of audio and video
Detailed identification of participant instead of just a 32
Session size estimation and scaling
scaled to 5% of data rate
Several types to carry a variety of information
Source description (SDES)
CNAME, email, location, name, ...
Sender report (SR)
Bytes sent -> estimated rate
Timestamp -> synchronization
Receiver report (RR)
Loss rate, interarrival jitter, roundtrip delay
Explicit leave (BYE)
Compound packets (SDES CNAME + RR)
RTCP traffic Control
RTP session scale: two to thousands of
RTCP traffic increases with session size
Want to keep to small fraction of data
Randomized response with rate decreasing as
number of participants increases
Give active senders more bandwidth
But limited by tolerable age of status
Single Stream Video Multicast
Adjust video output rate
refresh rate (?)
quantizer (color scheme 4:2:2, 4:1:1….)
movement detection threshold (what
Application can specify which of these
Single Stream Video Multicast
RTCP is used for feedback
Destination Set Grouping
Multiple replicated streams on different
Different quality and data rates.
Receivers can switch streams
Congestion due to presence of two
streams simultaneously on the same
Bandwidth Control Protocol
Congestion History Checking before stream
Local Area Bandwidth Limit restricts the
number of streams received in local area.
Layered Video Multicast
Disjoint layers on different addresses
Many protocols making different
Sender does not participate
Receivers share loss information
Receivers join and drop groups based on
these shared loss reports.
Receivers back off when they or other
receivers see congestion.
The higher the layer, the longer the back-off
Problems with RLM
Fast Leaves and Joins
Impact of failed experiments on
topologically unrelated receivers.
Arguably the most cited and most
TCP rate-based Congestion
Analyze TCP to come with a magic formula to
Bandwidth = 1.3 * MTU / (RTT * sqrt(Loss))
Adapt sender rate to match such a formula.
But what is RTT?
Let receivers make this decision.
Define loss thresholds based on this formula, for
If loss exceeds this threshold, drop a layer…