content? | string | 'main' | Content Attributes See https://www.rfc-editor.org/rfc/rfc4796#section-5 |
kindOrTrack | "audio" | "video" | MediaStreamTrack | undefined | Either audio or video |
direction? | MediaDirection | 'sendrecv' | Can be any of these sendrecv, sendonly, recvonly and inactive |
streams? | MediaStream[] | undefined | A list of MediaStream objects to add to the transceiver's RTCRtpReceiver |
sendEncodings? | MediaEncodingParameters[] | undefined | A list of RTCRtpEncodingParameters objects, each specifying the parameters for a single codec that could be used to encode the track's media |
degradationPreference? | RTCDegradationPreference | undefined | Specifies the preferred way the WebRTC layer should handle optimizing bandwidth against quality in constrained-bandwidth situations. The possible values are maintain-framerate, maintain-resolution, or balanced. The default value is balanced. Default balanced |
transceiver? | RTCRtpTransceiver | undefined | - |
allowChangeOfMediaDirection? | boolean | undefined | Whether to allow actively change of media direction |
relativeDirection? | boolean | undefined | The flag to indicate whether to use relative direction which corresponding to the offer, e.g. Offer "sendonly" <--> Answer "recvonly" From https://www.rfc-editor.org/rfc/rfc3264.html#section-6.1 > If a stream is offered as sendonly, the corresponding stream MUST be > marked as recvonly or inactive in the answer. If a media stream is > listed as recvonly in the offer, the answer MUST be marked as > sendonly or inactive in the answer. If an offered media stream is > listed as sendrecv (or if there is no direction attribute at the > media or session level, in which case the stream is sendrecv by > default), the corresponding stream in the answer MAY be marked as > sendonly, recvonly, sendrecv, or inactive. If an offered media > stream is listed as inactive, it MUST be marked as inactive in the > answer. |
jitterBufferTarget? | number | null | undefined | The jitterBufferTarget property of the RTCRtpReceiver interface is a DOMHighResTimeStamp that indicates the application's preferred duration, in milliseconds, for which the jitter buffer should hold media before playing it out. The application can use it to influence the tradeoff between playout delay and the risk of running out of audio or video frames due to network jitter. The value can be set to a positive value of no greater than 4000 milliseconds. |