Hi guys,
I really need some clarification about the interoperability between RTX Simulcast and Padding packets.
I am using VP8 simulcast on chrome as publisher, the stream goes into my SFU, and then relay the stream in different qualities to the participants. (obviously rewriting tid, tl0idx etc.)
Always worked like a charm between FF and chrome.
I always had RTX not implemented in my SFU and then disabled in SDPs.
SAY HELLO TO EDGE!
problem: EDGE NACKs only works on RTX channel (I had this information from fippo), meaning if you say in the answer you doesn't support RTX, EDGE will never send you a NACK but only PLIs, even if it says it supports NACKs (WTF??)
Ok then, try to implement RTX on server... done.
FIRST STRANGE NOTED THING:
when I try to publish from CHROME, in simulcast, VP8 (payload 96) with RTX enabled (payload 97), I receive the first packets as padding in the RTX channel:
3|agent | ***************
3|agent | LENGHT: 244
3|agent | ***************
3|agent | RTP PACKET
3|agent | Header:
3|agent | version: 2
3|agent | has padding: true
3|agent | has extension: true
3|agent | cc: 0
3|agent | marker: false
3|agent | type: 97
3|agent | sequence number: 2314
3|agent | timestamp: 0
3|agent | synchronization source: 18740306
3|agent | Extension:
3|agent | code: 48862 (One-Byte Header)
3|agent | length: 1
3|agent | Extensions:
3|agent | id: 3 data: 00011110 10010100 01111011
3|agent | original seq number: 54128
3|agent | Padding:
3|agent | bytes: 224
then sometimes I receive a copy of a previous packet (already sent) few times, but with the padding marker set to 0:
3|agent | ***************
3|agent | LENGHT: 366
3|agent | ***************
3|agent | RTP PACKET
3|agent | Header:
3|agent | version: 2
3|agent | has padding: false
3|agent | has extension: true
3|agent | cc: 0
3|agent | marker: true
3|agent | type: 97
3|agent | sequence number: 2316
3|agent | timestamp: 2948204219
3|agent | synchronization source: 18740306
3|agent | Extension:
3|agent | code: 48862 (One-Byte Header)
3|agent | length: 1
3|agent | Extensions:
3|agent | id: 3 data: 00100001 01011011 00100011
3|agent | original seq number: 9486
Any idea why? It seems it retransmits some packets but I never asked them with a NACK or PLI.
Then when the REMBs generated from server are high enough, it stop sending both padding and retransmission packets.
It doesn't affect the result, they are seen as retransmitted from server and dropped.
Just curious why chrome is behaving like this.
Now that RTX is implemented, I have to switch the mechanism to my Padding Generator for subscribers in order to raise their REMBs, since at first I'm sending the base quality layer and I need to probe their bandwidth to know if I can raise the resolution.
On non RTX implementation, I calculate a padding bitrate and after an end of packet I send a burst of only padding packets with subsequents sequence number.
It works flawlessly.
But now that I have to support RTX how should I proceed?
On chrome and Firefox, sending the padding in the main (non rtx) channel still works with no problem but EDGE start sending nacks for every padding packet I send to him (this is wrong I think).
So I said, hey just try to implement this mechanism the way chrome does.
So I started to send them in the RTX channel, with the correct payload, the timestamp of the last sent packet, a random starting but increasing sequence number, the SSRC of the RTX channel, padding marker set to true and tried both to set the marker of ending packet to false (as should be done I think) but also with true.
Results:
EDGE when receiving lots of RTX packets (also if they are padding), stops sending RR for the main video stream, sometimes it sends an RR for the RTX channel. But the REMBs are still not growing so my bandwidth estimator never decide to switch to an higher quality layers.
So I tried to reverse engineer what EDGE sends as publisher.
It seems it sends padding (also if it is a non-simulcast stream since edge doesn't support that in VP8) in the RTX channel, the same way I was sending to him.
Also tried with chrome, same result, if I send him padding on the RTX side, it just ignores it and don't raise REMBs.
So what's the pattern?
only publishers are allowed to send padding in the RTX channel?
Since my server acts as a "publisher" when other people subscribe to the stream, how am I supposed to raise their REMBs when they support RTX?
I tried everything but I cannot make them work together, especially EDGE that seems to ignores every type of padding, no matter in which channel and which payload it receive.
FUN THING:
If you do a p2p call, EDGE to EDGE, in VP8 with RTX support in the SDPs and then use some tool to cap the bandwidth, the resolution scales to a very poor image, but if you release the cap, it never turns back to normal.
So I think it's another EDGE bug, which prevents us to implement a decent call in VP8.
But if someone out there is more expert in the field, can you please "enlighten" me of how things works?
Many many Thanks,
Francesco.
