Geek Answers Handbook

How to handle packet loss when recording video mail to a server via WebRTC

We use licode MCU to stream recorded video from Google Chrome to the server. A second instance of Google Chrome is not required to process reviews, and the server must do this.

One thing we are faced with is when packets with packet loss are deleted and the video goes out of sync. This results in very poor video quality.

bad video quality

ExternalOutput.cpp has a place where it discovers that the current packet of received data has not increased monotonously. Here you can see that it discards the current frame and resets the search state.

I would like to know how to change this so that it can recover from the loss of this package. Does the NACK packet represent the current sequence number? I also read that there is a mode in which Google chrome sends RED packets (redundant) to combat packet loss.

+7
google-chrome webrtc packet-loss licode
source share
1 answer

Media processing applications have two main different levels:

The transport layer is independent of the codec and processes RTTP / generic RTCP packets. At this level, there are several mechanisms to deal with packet loss / delay / reordering:

  • Jitter buffer (handles packet delays and reordering)
  • Common RTCP backlinks (notifies the source address of a lost packet)

There are also several mechanisms at the codec level to combat quality degradation:

To overcome Licode , you need to:

  • First of all, it ignores any packet delays and reordering. So you have to implement a mechanism (jitter buffer) that will handle packet congestion / network jitter and identify a lost packet (maybe you could reuse the webrtc / freeswitch mechanisms)

  • When your application detects a lost packet, you must send a feedback ( RTCP NACK ) to the remote peer

  • You should also try to process ffmpeg (used to decode the video and save it to a file) decoding errors and send FIR (Fast Intra Request) / PLI to the remote peer to request key frames in case of errors.

Note that p.2.3 requires proper explicit negotiation (via SDP).

Only after going through all these cases can you take a look at FECC / RED, because it is definitely more difficult to handle and implement.

+3
source share

More articles:


All Articles