I'm a newbie with RRTCC and I really dont understand how RRTCC adjusts incoming media bitrate.
I tried to read Internet Draft of RRTCC but cannot figure it out: https://datatracker.ietf.org/doc/html/draft-alvestrand-rmcat-congestion-03
It calculates the estimated bandwidth based on delay and loss, so what's next?
How it can directly control the sending rate to control congestion?
The RTP receiver doesn't directly control the sending rate. It just sends status information to the RTP sender, which is the only one capable of controlling its own sending rate.
draft-alvestrand-rmcat-congestion has been replaced by draft-ietf-rmcat-gcc so I recommend that you use the later one.
In section 2. System model it explains that the RTP receiver should also act as a RTCP sender, in order to send REMB messages to the RTP sender. These messages should be sent by the RTP receiver as soon as it detects any congestion, and then keep sending it at a rate of once per second even if no congestion is happening. Then the RTP sender uses the information in the received message to decide if the transmission bitrate can be raised or should be immediately lowered.
I am one of the authors of the draft. If you are interested in understanding the design criteria you can also take a look at this paper:
G. Carlucci, L. De Cicco, S. Holmer, and S. Mascolo
Analysis and Design of the Google Congestion Control for Web Real-time Communication (WebRTC)
Proc. ACM Mmsys 2016, Klagenfurt, Austria, May 2016
which is available for download at http://c3lab.poliba.it/images/6/65/Gcc-analysis.pdf.
Related
I am capturing my screen in real-time and encoding them using the vp9 codec (using JNI). encoded frames are I-frame or P-frame. then I divide them into chunks (sub-frames) and send them to the network. But at receiving end there has been some natural packet loss and even a single miss of sub-frames causing the inability to reconstruct corresponding I/P - frames. I tried to simulate (randomly throwing out some sub-frames) the same thing locally and the same things happened. Doesn't VP9 codec has some built-in packet loss handling? If so, how to enable them and how can it perform well to a certain percentage?
And if there is no built-in packet loss handling Do I have to implement FIR or FEC manually? and where to follow?
Thanks in advance.
Common way to send video stream is RTP protocol based on UDP, among other libs WebRTC also uses this transport under hood. Each encoded frame before sending is packetized, i.e. splitted to one or several RTP packets. In this context term "packet loss" means RTP packet loss. These losses are handled by sender peer using RTCP Receiver Reports from the other peer: the sender can retransmit lost packets. So, such reconstruction is not related to VP9 or any other specific codec.
As vp9 is a entropy coding, even a single packet missing causes inability to reconstruct the I/P frame. Even inability to reconstruct I frame cause inability to construct all subsequent & dependent P frame's. As I am using raw vp9 I have to implement any kind of retransmission or redundancy.
There is a concept of error_resilient packet or golden frame which can be called as budget version of I-frame which I need to send at certain interval from sender so that the I frame & subsequent P
frame's will have some resiliency (I tried it and failed generating golden frame from encoder by enabling the parameter, maybe I will have to generate it myself).
I have been trying to figure out a way to calculate the following:
Bandwidth, Latency, Current Upload, and Download speed.
And have been confused with the values I am getting for the INBOUND-RTP, OUTBOUND-RTP, & REMOTE-INBOUND-RTP.
In my head, I was thinking about inbound-rtp as a collection of stats for all incoming data.
which apparently is wrong, since different stats for that type always stays Zero
The current setup uses chrome as a 2 connecting Clients, and a Media Server, with client instances running on "localhost"
The terminology used on MDN is a bit terse, so here's a rephrasing that I hope is helpful to solve your problem! Block quotes taken from MDN & clarified below. For an even terser description, also see the W3C definitions.
outbound-rtp
An RTCOutboundRtpStreamStats object giving statistics about an outbound RTP stream being sent from the RTCPeerConnection.
This stats report is based on your outgoing data stream to your peers. This is the measurement taken from the perspective of just that oubound RTP stream, which is why information that involves your peers (round trip time, jitter, etc.) is missing, because those can only be measured with an understanding of the peer's processing of your stream.
inbound-rtp
Statistics about an inbound RTP stream that's currently in use by this RTCPeerConnection, in an RTCInboundRtpStreamStats object.
By contrast to the Outbound RTP statistics, this stats report contains data about the inbound data stream you are receiving from your peer(s). Notice that if you do not have any connected peers your call to getStats does not include this report type at all.
remote-inbound-rtp
Contains statistics about the remote endpoint's inbound RTP stream; that stream corresponds to the local endpoint's outbound RTP stream. Using this RTCRemoteInboundRtpStreamStats object, you can learn how the well the remote peer is receiving data.
This stats report provides details about your outbound rtp stream from the perspective of the remote connection. That is to say that this stats report provides an analysis about your outbound-rtp stream from the perspective of the remote server that is handling your stream on the other side.
I'm on the MDN writing team at Mozilla and happened upon this just now. I've taken some of the information from this conversation and applied it back to the article about RTCStatsType. There's more to improve there still, but I wanted to thank you for that insight!
Always feel free to sign up for an MDN account and update any content you see that's inaccurate or incomplete! Or you can file an issue and we'll see what we can do.
I'm trying to implement the UPLINK of a Ground Station controlling a small satellite. The idea is that the link should stay always active in between each transmitted telecommand. For this, I need to insert some DUMMY or IDLE sequence bytes such as 0xAA or similar.
I have found that some people already faced a similar issue and posted their questions here:
https://www.ruby-forum.com/t/constant-carrier-digital-transmission/163379
https://lists.gnu.org/archive/html/discuss-gnuradio/2016-08/msg00148.html
So far, the best I could achieve was to modify the EventStream Source block from https://github.com/osh/gr-eventstream in order to preload the vectors with my dummy sequence (i.e. 0xAA) instead of preloading them with zeroes. This is a general overview of the GNURadio graph I'm using:
GNURadio Flowgraph Picture
This solution however introduces a huge latency and the sent message does not appear at the output until a huge amount of time has expired (in the order of several seconds).
Is there a way of programming the USRP using GNURadio so that it constantly sends a fixed sequence which should only be interrupted when an incoming message is passed? I assume that the USRP has the ability of reading tagged streams in order to schedule transmissions. However, I'm not sure how to fit this in my specific application.
Thanks beforehand!
Joa
I believe this could be done using a TCP or UDP source block.
Your control information could be sent to the socket using TCP/UDP. GNU Radio would then collect and transmit the packets. Your master control program would then have to handle the IDLE stuffing but solving the problem external to GNU Radio is easier.
Your master control program would basically do the following:
1. tx control data as needed
2. if no control data ready before next packet must be sent send an IDLE packet
USB 2.0 specifies 4 types of transfers (in section 5.4 Transfer Types):
Control Transfers
Isochronous Transfers
Interrupt Transfers
Bulk Transfers
Section 5.8 says that Bulk Transfers provide:
Access to the USB on a bandwidth-available basis
Retry of transfers, in the case of occasional delivery failure due to errors on the bus
Guaranteed delivery of data but no guarantee of bandwidth or latency
(Emphasis mine.)
I don't see a similar statement for Control Transfers. Do they also guarantee delivery? If not, how are users expected to handle failures?
Please provide a citation(s) to support your answer.
The USB specification provides robust error detection and recovery for control transfers. The control transfer will either be completed or the USB host will know that it failed, and I think that's what "guaranteed delivery" is supposed to mean. This is important because control transfers are used to set up the device when you plug it into a computer and they are also used for many important purposes by the various USB device classes (e.g. they are used to set the baud rate of a serial port on a USB CDC ACM device).
From section 5.5.5 of the USB 2.0 specification:
The USB provides robust error detection and recovery/retransmission for errors that occur during control transfers. Transmitters and receivers can remain synchronized with regard to where they are in a control transfer and recover with minimum effort. Retransmission of Data and Status packets can be detected by a receiver via data retry indicators in the packet. A transmitter can reliably determine that its corresponding receiver has successfully accepted a transmitted packet by information returned in a handshake to the packet. The protocol allows for distinguishing a retransmitted packet from its original packet except for a control Setup packet. Setup packets may be retransmitted due to a transmission error; however, Setup packets cannot indicate that a packet is an original or a retried transmission.
The only transfer type without guaranteed delivery is isochronous. Also, the start of frame (SOF) packets don't have guaranteed delivery.
I have an embedded device (source) which is sending out a stream of (audio) data in chunks of 20 ms (= about 330 bytes) by means of a UDP packets. The network volume is thus fairly low at about 16kBps (practically somewhat more due to UDP/IP overhead). The device is running the lwIP stack (v1.3.2) and connects to a WiFi network using a WiFi solution from H&D Wireless (HDG104, WiFi G-mode). The destination (sink) is a Windows Vista PC which is also connected to the WiFi network using a USB WiFi dongle (WiFi G-mode). A program is running on the PC which allows me to monitor the amount of dropped packets. I am also running Wireshark to analyze the network traffic directly. No other clients are actively sending data over the network at this point.
When I send the data using broadcast or multicast many packets are dropped, sometimes upto 15%. However, when I switch to using UDP unicast, the amount of packets dropped is negligible (< 2%).
Using UDP I expect packets to be dropped (which is OK in my Audio application), but why do I see such a big difference in performance between Broadcast/Multicast and unicast?
My router is a WRT54GS (FW v7.50.2) and the PC (sink) is using a trendnet TEW-648UB network adapter, running in WiFi G-mode.
This looks like it is a well known WiFi issue:
Quoted from http://www.wi-fiplanet.com/tutorials/article.php/3433451
The 802.11 (Wi-Fi) standards specify support for multicasting as part of asynchronous services. An 802.11 client station, such as a wireless laptop or PDA (not an access point), begins a multicast delivery by sending multicast packets in 802.11 unicast data frames directed to only the access point. The access point responds with an 802.11 acknowledgement frame sent to the source station if no errors are found in the data frame.
If the client sending the frame doesnt receive an acknowledgement, then the client will retransmit the frame. With multicasting, the leg of the data path from the wireless client to the access point includes transmission error recovery. The 802.11 protocols ensure reliability between stations in both infrastructure and ad hoc configurations when using unicast data frame transmissions.
After receiving the unicast data frame from the client, the access point transmits the data (that the originating client wants to multicast) as a multicast frame, which contains a group address as the destination for the intended recipients. Each of the destination stations can receive the frame; however, they do not respond with acknowledgements. As a result, multicasting doesnt ensure a complete, reliable flow of data.
The lack of acknowledgments with multicasting means that some of the data your application is sending may not make it to all of the destinations, and theres no indication of a successful reception. This may be okay, though, for some applications, especially ones where its okay to have gaps in data. For instance, the continual streaming of telemetry from a control valve monitor can likely miss status updates from time-to-time.
This article has more information:
http://hal.archives-ouvertes.fr/docs/00/08/44/57/PDF/RR-5947.pdf
One very interesting side-effect of the multicast implementation (at the WiFi MAC layer) is that as long as your receivers are wired, you will not experience any issues (due to the acknowledgement on the receiver side, which is really a unicast connection). However, with WiFi receivers (as in my case), packet loss is enormous and completely unacceptable for audio.
Multicast does not have ack packets and so there is no retransmission of lost packets. This makes perfect sense as there are many receivers and it's not like they can all reply at the same time (the air is shared like coax Ethernet). If they were all to send acks in sequence using some backoff scheme it would eat all your bandwidth.
UDP streaming with packet loss is a well known challenge and is usually solved using some type of forward error correction. Recently a class known as fountain codes, such as Raptor-Q, shows promise for packet loss problem in particular when there are several unreliable sources for the data at the same time. (example: multiple wifi access points covering an area)