From 8c7db8bf92a937ff369a6adfa5cdc04982139b30 Mon Sep 17 00:00:00 2001 From: Ankur Dubey Date: Wed, 13 Jul 2022 17:01:02 +0530 Subject: [PATCH] Doc : fix some minor typos (#43) --- .../v3/libmediasoupclient/api/SendTransportListener.md | 4 ++-- .../v3/libmediasoupclient/api/TransportListener.md | 2 +- documentation/overview.md | 2 +- documentation/v3/libmediasoupclient/design.md | 2 +- documentation/v3/mediasoup/design.md | 2 +- documentation/v3/mediasoup/rtp-parameters-and-capabilities.md | 2 +- documentation/v3/scalability.md | 4 ++-- 7 files changed, 9 insertions(+), 9 deletions(-) diff --git a/_includes/documentation/v3/libmediasoupclient/api/SendTransportListener.md b/_includes/documentation/v3/libmediasoupclient/api/SendTransportListener.md index 8031dd6..db7f3d9 100644 --- a/_includes/documentation/v3/libmediasoupclient/api/SendTransportListener.md +++ b/_includes/documentation/v3/libmediasoupclient/api/SendTransportListener.md @@ -71,7 +71,7 @@ std::future MySendTransportListener::OnProduce( std::make_exception_ptr("'id' missing/invalid in response")); } - // Fullfill the promise with the id in the response and return its future. + // Fulfil the promise with the id in the response and return its future. promise.set_value(idIt->get()); return promise.get_future(); @@ -135,7 +135,7 @@ std::future MySendTransportListener::OnProduceData( std::make_exception_ptr("'id' missing/invalid in response")); } - // Fullfill the promise with the id in the response and return its future. + // Fulfil the promise with the id in the response and return its future. promise.set_value(idIt->get()); return promise.get_future(); diff --git a/_includes/documentation/v3/libmediasoupclient/api/TransportListener.md b/_includes/documentation/v3/libmediasoupclient/api/TransportListener.md index 9bdcc6a..ddc4fcc 100644 --- a/_includes/documentation/v3/libmediasoupclient/api/TransportListener.md +++ b/_includes/documentation/v3/libmediasoupclient/api/TransportListener.md @@ -55,7 +55,7 @@ std::future MyTransportListener::OnConnect( // [...] Let's assume code execution continues once we get a success response // from the server. - // Fullfill the promise and return its future. + // Fulfil the promise and return its future. promise.set_value(); return promise.get_future(); diff --git a/documentation/overview.md b/documentation/overview.md index 0c587e7..8163f69 100644 --- a/documentation/overview.md +++ b/documentation/overview.md @@ -6,7 +6,7 @@ anchors : true # Overview -An [SFU](https://webrtcglossary.com/sfu/) (Selective Forwarding Unit) receives audio and video streams from endpoints and relays them to everyone else (endpoints send one and receive many). Each receiver endpoint can select which streams and spatial/temporal layers it receives. Compared to a mixer or [MCU](https://webrtcglossary.com/mcu/) (Multipoint Control Unit) this design leads to a better performance, higher throughput and less latency. It's highly scalable and requires much less resources given that it does not transcode or mix media. +An [SFU](https://webrtcglossary.com/sfu/) (Selective Forwarding Unit) receives audio and video streams from endpoints and relays them to everyone else (endpoints send one and receive many). Each receiver endpoint can select which streams and spatial/temporal layers it receives. Compared to a mixer or [MCU](https://webrtcglossary.com/mcu/) (Multipoint Conferencing Unit) this design leads to a better performance, higher throughput and less latency. It's highly scalable and requires much less resources given that it does not transcode or mix media. Since endpoints get the other endpoints' media separately, they can have a personalized layout and choose which streams to render and how to display them. diff --git a/documentation/v3/libmediasoupclient/design.md b/documentation/v3/libmediasoupclient/design.md index 65b889a..3ce60d6 100644 --- a/documentation/v3/libmediasoupclient/design.md +++ b/documentation/v3/libmediasoupclient/design.md @@ -32,4 +32,4 @@ Examples: * [device.GetRtpCapabilities()](/documentation/v3/libmediasoupclient/api/#device-GetRtpCapabilities) blocks the current thread until capabilities are internally retrieved and returns them. * [sendTransport.Produce()](/documentation/v3/libmediasoupclient/api/#SendTransport-Produce) internally performs SDP offer/answer in the underlaying `RTCPeerConnection` instance and blocks the thread until done. -* The [SendTransport::Listener::OnProduce](/documentation/v3/libmediasoupclient/api/#SendTransportListener-OnProduce) event returns a `std::future` and waits for the application to fullfill it (once it communicates to the server). +* The [SendTransport::Listener::OnProduce](/documentation/v3/libmediasoupclient/api/#SendTransportListener-OnProduce) event returns a `std::future` and waits for the application to fulfil it (once it communicates to the server). diff --git a/documentation/v3/mediasoup/design.md b/documentation/v3/mediasoup/design.md index 48ea6fc..01a8951 100644 --- a/documentation/v3/mediasoup/design.md +++ b/documentation/v3/mediasoup/design.md @@ -12,7 +12,7 @@ Unlike other existing SFU implementations, mediasoup is not a standalone server const mediasoup = require("mediasoup"); ``` -Thus internally, mediasoup can be splitted into two separete components: +Thus internally, mediasoup can be splitted into two separate components: * a JavaScript layer exposing a modern ECMAScript API for Node.js, and * a set of C/C++ subprocesses that handle the media layer (ICE, DTLS, RTP and so on). diff --git a/documentation/v3/mediasoup/rtp-parameters-and-capabilities.md b/documentation/v3/mediasoup/rtp-parameters-and-capabilities.md index 2235ced..0dd8dd8 100644 --- a/documentation/v3/mediasoup/rtp-parameters-and-capabilities.md +++ b/documentation/v3/mediasoup/rtp-parameters-and-capabilities.md @@ -348,7 +348,7 @@ These parameters influence the mediasoup operation by enabling or disabling some Parameter | Type | Description | Required | Default -------------- | ------- | ------------- | -------- | --------- -"useinbandfec" | Number | If 1, mediasoup will use the worst packet fraction lost in the RTCP Receiver Report received from the consuming endpoints and use it into the Receiver Report that mediasoup sends to the OPUS producer endpoint. This will force it to generate more in-band FEC into the OPUS packets to accomodate to the worst receiver. | No | 0 +"useinbandfec" | Number | If 1, mediasoup will use the worst packet fraction lost in the RTCP Receiver Report received from the consuming endpoints and use it into the Receiver Report that mediasoup sends to the OPUS producer endpoint. This will force it to generate more in-band FEC into the OPUS packets to accommodate to the worst receiver. | No | 0 "usedtx" | Number | If 1, mediasoup will not consider the stream as inactive when there is no RTP traffic. Same behavior is achieved by indicating `dtx`: `true` in the corresponding encoding in the RTP send parameters. | No | 0 diff --git a/documentation/v3/scalability.md b/documentation/v3/scalability.md index 7bb2123..e3793db 100644 --- a/documentation/v3/scalability.md +++ b/documentation/v3/scalability.md @@ -64,10 +64,10 @@ It's also perfectly possible to inter-communicate mediasoup routers running in d
When broadcasting a video stream to many viewers (hundreds or thousands of consumers) it's important to be aware of how video RTP transmission typically works: -* A viewer may eventually loose video packets so would request packet retransmission to mediasoup. Retranmissions are handled per transport (they do not reach the broadcaster endpoint) so there is no limitation here. +* A viewer may eventually loose video packets so would request packet retransmission to mediasoup. Retransmissions are handled per transport (they do not reach the broadcaster endpoint) so there is no limitation here. * A viewer may connect or reconnect, or may change its preferred spatial layer, or may just loose too many packets. Any of those circumstances would imply a video key frame request by means of a RTCP PLI or FIR that reaches the broadcaster endpoint. * Upon receipt of a video PLI or FIR, the encoder in the broadcaster endpoint generates a video key frame which is a video packet much bigger than the usual ones. -* If the encoder receives many PLIs or FIRs (although mediaoup protects the producer endpoint by preventing it from receiving more than one PLI or FIR per second) the sending bitrate of the broadcaster endpoint would increase by 2x or 3x. This may be a problem for the producer endpoint and also for viewers that will receive much more bits per second. +* If the encoder receives many PLIs or FIRs (although mediasoup protects the producer endpoint by preventing it from receiving more than one PLI or FIR per second) the sending bitrate of the broadcaster endpoint would increase by 2x or 3x. This may be a problem for the producer endpoint and also for viewers that will receive much more bits per second. - *NOTE:* This may be mitigated by increasing the default [keyFrameRequestDelay](/documentation/v3/mediasoup/api/#ProducerOptions) value, although that would cause longer "black-video" periods. * And that is the problem.