Live Video Streaming

There are three main categories of live video streaming:

1. non-interactive video streaming of sport events, here the tolerated latency can be 0.5s-1s.
2. low-latency interactive video  for video conference, here the tolerable latency is ~300ms
3. ultra-low latency cloud gaming, here latency should be 100-150ms at most.

 

B-frames are avoided in low latency streaming, the following figure shows that the original order I B B P was encoded and transmitted as I P B B and consequently displayed with the latency of two frame periods, where δ is transmission duration:

 

Due to changing of network condition Sender can be notified by Receiver on measured or estimated  throughput.  Upon getting corresponding feedback from Receiver the Adaptive Bitrate mechanism chooses the highest bitrate that is less than the last throughput measured.

 

Quality Metrics of Media Streaming (not necessarily live streaming):

Startup metric : related to the time it takes the media asset to load and/or play.

Buffer:  related to buffering and estimate “stalling”, “stuttering” and similar effects during playback. In case of non-live streaming seeking is also checked.

Quality:  related to the adaptation for adaptive streaming (e.g., quality levels and quality switches), as well as picture quality for video (e.g., resolution and re-scaling).

 

 

Bitstream Errors

Bitstream errors are inevitable therefore two techniques are commonly used to correct these network faults

• Forward Error Correction (FEC)

FEC packets add overhead, they are sent whether they are needed by the receiver or not.

• Automatic Repeat reQuest (ARQ),  two-way connection between the Packet Sender and Packet Receiver required. In addition caching data at the Packet Sender is necessary to re-transmit lost packets.
  

 

the pictures taken from Haivision white paper “SRT – A new open source protocol for low-latency video transport over the internet”

      ARQ can be disabled for the N-th packet:

               if  current_time + RTT > T_d(N)

RTT is an estimated round trip
T_d(N) is the time when N-th packet is scheduled for decoding.

 

 

End-to-end delay:

In live video streaming End-to-End delay is measured from capturing of the image by a camera and its decoding (or presentation) at user’s display.

In Cloud-Gaming End-to-End delay (or Response Delay) is measured from pressing on a button “fire” and appearance of the fire on user’s screen.  

End-to-End delay includes the queuing delay, propagation delay, decoding delay etc.

For example, the queuing delay refers to packet buffering in the sender, receiver and middle network nodes during packet transmission.