Skip to content

Instantly share code, notes, and snippets.

@murillo128

murillo128/issues.md

Created April 13, 2016 10:19
Show Gist options
  • Save murillo128/95c75e8ab205980012869d3efead98e0 to your computer and use it in GitHub Desktop.
Save murillo128/95c75e8ab205980012869d3efead98e0 to your computer and use it in GitHub Desktop.
Download ZIP
ORTC issues
Raw
issues.md

#API not based on use cases There are three main use cases:

  • Normal usage -> 1 RTPSender => 1 media codec, 1 encoding, 1 media stream
  • Simulcast -> 1 RTPSender => 1 media codec, n encodings, n media streams (1 media stream per encoding)
  • SVC -> 1 RTPSender => 1 media codec, n encodings, 1 media stream

But the API allows to configure the parameters with valid edge cases:

  • Multiple media codecs per RTPSender (VP8 + H264)
  • Same ssrc sent by two RTPSenders (given that payloads don't collide)

Q: Are they going to be supported by all browsers? I don't think so.

#Double references

API allows to create inconsistent parameters easily

A well-formed API should enforce data consistency, but in order to a RTCRtpParameter to be valid, all this checks must be passed

  • There are no two codecs with same payloadType
  • For each codecPayloadType in the encodings, there must be a codec in codecs with that payloadType
  • If there are two encodings with same ssrc, they must have same rtx.ssrc
  • If there are two encodings with same ssrc, they must have same fec.mechanishm and fec.ssrc
  • If thre is an encoding with fec.mechanishm=="red", there must be an entry for RED in codecs, and a encoding with RED codec payload and same ssrc
  • If thre is an encoding with fec.mechanishm=="red+ulpfec", there must be an entry for RED and FEC in codecs, and one encoding with RED codec payload and one for FEC codec payload, both with same ssrc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment