Advanced network accounting notes (VIII)

Streaming video

Challenge

Continuous playback limit

• Once it starts playing , Reception rate > Playback rate
• The played frame should be received in advance , It's no use arriving late
• Network delay jitters , Cache required
• The first frame is not played immediately , A delay is required

other

• User interaction ： Pause , Forward , backward , Jump
• Packet loss retransmission

buffer

• Absorption end-to-end delay variation ： A frame arrives late , As long as there is data in the buffer, it can be played continuously
• Compensate for end-to-end broadband fluctuations ： Instantaneous path throughput < Play bit rate , Download rate < Consumption rate , As long as there is data in the buffer, it can be played continuously , The condition is that the path average throughput >= Playback bandwidth
  Client side buffering is required , Because network latency changes , Path average throughput change

Average injection rate $x$ & Playback rate $r$

• $x<r$： Cache empty , Carton
• $x>r$： Cache is not empty , Weak playback delay is large enough , It can absorb $x$ change

Initial playback tradeoffs

• Large playback delay , The cache becomes empty, and the possibility of playback pause is small

The extreme case is that the download is finished and the playback is finished , Non fluidization

• Long waiting time for large users due to the introduction of delay

technology

• UDP Fluidization
• HTTP Fluidization
• The adaptive HTTP Fluidization

UDP

The server sends data to the client at a constant rate
routine ： Sending rate = Encoding rate = Constant rate
Due to congestion control , Rate change at receiving end

cache

Introduce a small playback delay $(2-5s)$ Smooth jitter

Error recovery

Time allows for implementation in the application layer

RTP

Encapsulate the required multimedia types , timestamp , Serial number
RTP->UDP

RTSP

And RTP coordination , Let the client and the server control commands interactively
Such as ： Pause , Play

UDP May not be able to penetrate the firewall

UDP Fluidization thought

• network bandwidth , The jitter is uncontrollable
• Try to maintain a constant rate at the source

UDP Fluidization problem

• client - Bandwidth changes between servers , unpredictable , Constant bit rate UDP Streaming does not provide continuous playback
• A control protocol is required ,RTSP The server , Increase large-scale deployment VOD Server cost
• A firewall

HTTP Fluidization

Deployment run

• Think of video as HTTP object , Corresponding URL
• Client request , Establishing a connection , issue HTTP GET
• In congestion control , Flow control conditions allow , Send the file as far as possible
  • Rate change
• Client application layer buffer , Start playing when the threshold is reached

problem

TCP Not suitable for streaming services

• Network bandwidth and latency are beyond the control of the host , It needs to be done at the source end
• introduce TCP Wave superposition
• The bit rate is out of order before it is transmitted

HTTP Fluidization thinking

• In essence, the average bandwidth on the road > Play bit rate
• introduce TCP Superimpose larger fluctuations , But with buffering , Prefetching Technology
• utilize TCP The advantage is when the bandwidth is large , It can be transmitted to the client as much as possible
• Reverse pressure when the client buffer is full , Let the sender not send for the time being , It won't overflow

cost

• The application layer introduces a larger playback delay , For smoothing TCP Change in delivery rate
• The reason is that the network jitters and bandwidth changes , as well as TCP Self flow control . Congestion control introduces additional jitter , Bandwidth changes , Superimposed fluctuations

benefits

• Easy to pass through firewall
• There is no need to RTSP service

application

Applicable to storage data streaming , Not suitable for real-time data streaming

• TCP Introduce more delay variations , Impact interaction and real-time
• Can't use TCP Prefetch benefits

Cannot prefetch ungenerated data

cache

Received a certain number , Then the client plays according to the playing code rate

Two level cache

TCP + application layer

• Application cache = file size ： Non fluidization
• Pause play ： Reverse pressure , Application cache full block TCP Hand in , Block the server TCP transmission ,TCP Cache full , The server stops
• Normal playback , The cache rate is higher than the playback rate ：TCP Cache full , Stop transmission
• The cache rate is lower than the playback rate ： Cache dissatisfaction , Carton

Prefetch

• The client is higher than the consumption rate （ As soon as possible ） Prefetch data , Prepare for the play
• Natural and TCP binding