搜索 | 用户支持

防范以用户支持为名的诈骗。我们绝对不会要求您拨打电话或发送短信,及提供任何个人信息。请使用“举报滥用”选项报告涉及违规的行为。

详细了解

Is it possible to disable VP8 error concealment for WebRTC?

  • 2 个回答
  • 1 人有此问题
  • 7 次查看
  • 最后回复者为 Robert Kirnum

more options

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.

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.

被采纳的解决方案

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.

定位到答案原位置 👍 1

所有回复 (2)

more options

由cor-el于修改

more options

选择的解决方案

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.