Is it possible to disable VP8 error concealment for WebRTC?
Chrome appears to disable VP8 error concealment when rtcp-fb nack is negotiated when setting up a connection (SIP / SDP). I have not been able to get Firefox to disable error concealment. I am also unable get Firefox to enable rtcp-fb nack though I am not certain this will disable VP8 error concealment as on Chrome.
Wybrane rozwiązanie
From http://www.ietf.org/rfc/rfc2327.txt SDP: Session Description Protocol
6. SDP Specification
…
Text records such as the session name and information are bytes strings which may contain any byte with the exceptions of 0x00 (Nul), 0x0a (ASCII newline) and 0x0d (ASCII carriage return). The sequence CRLF (0x0d0a) is used to end a record, although parsers should be tolerant and also accept records terminated with a single newline character. By default these byte strings contain ISO-10646 characters in UTF-8 encoding, but this default may be changed using the `charset' attribute.
Looks like the Firefox SDP parser requires a carriage return ('\r'), it is unable to process attributes ending in just a newline ('\n'). I guess the RFC does indicate SHOULD as opposed to SHALL.
Przeczytaj tę odpowiedź w całym kontekście 👍 1Wszystkie odpowiedzi (2)
Maybe check out the Firefox source code about rtcp-fb nack.
Zmodyfikowany przez cor-el w dniu
Wybrane rozwiązanie
From http://www.ietf.org/rfc/rfc2327.txt SDP: Session Description Protocol
6. SDP Specification
…
Text records such as the session name and information are bytes strings which may contain any byte with the exceptions of 0x00 (Nul), 0x0a (ASCII newline) and 0x0d (ASCII carriage return). The sequence CRLF (0x0d0a) is used to end a record, although parsers should be tolerant and also accept records terminated with a single newline character. By default these byte strings contain ISO-10646 characters in UTF-8 encoding, but this default may be changed using the `charset' attribute.
Looks like the Firefox SDP parser requires a carriage return ('\r'), it is unable to process attributes ending in just a newline ('\n'). I guess the RFC does indicate SHOULD as opposed to SHALL.