Implement NACK+RTX support defined by RFC4588 #45
Conversation
|
Hi Sergio, thank you for your PR. Could you please provide some background information for this PR in the description? The patch will be generated based on the title and description, and it will be sent via email to the FFmpeg community. Therefore, a detailed description is important for the maintainers to review this PR. |
|
RTP retransmission described in RFC4588 (RTX) is an effective packet loss recovery technique for real-time applications with relaxed delay bounds. This PR provides a minimal implementation for RTX and RTCP NACK (RFC3940) and its associated SDP signaling and negotiation. |
winlinvip
force-pushed
the
workflows
branch
3 times, most recently
from
3294e09 to
4aa17ba
Compare
JackLau1222
force-pushed
the
nack-rtx
branch
4 times, most recently
from
ec1b1bf to
809f0a5
Compare
Good newsThis patch has been tested with Pion and Janus, and it works well. However, this patch need to depend on some other patch(not in FFmepg master for now) otherwise you might run into problems, so I put these patches here: In the coming days, I'll add pion and janus tests into workflow, improve this patch, then submit this patch to FFmpeg developers mail list |
winlinvip
changed the title
winlinvip
changed the title
Good newsThis patch has been tested with Pion and Janus, and it works well. However, this patch need to depend on some other patch(not in FFmepg master for now) otherwise you might run into problems, so I put these patches here: In the coming days, I'll add pion and janus tests into workflow, improve this patch, then submit this patch to FFmpeg developers mail list
|
The patch is still generated by git config author.
refer to https://www.ffmpeg.org/developer.html#Submitting-patches-1 add header "X-Unsent: 1" add email recipients Signed-off-by: Jack Lau <[email protected]>
All files in the .github directory pertain to CI/CD and should be ignored; they should not be included in the patch.
This PR refer to ossrs#39 and ossrs#38 --------- Signed-off-by: Jack Lau <[email protected]>
ghost
Signed-off-by: Jack Lau <[email protected]>
decrypt the SRTCP pakcet, get the right pid and blp data add more comments Signed-off-by: Jack Lau <[email protected]>
Signed-off-by: Jack Lau <[email protected]>
Signed-off-by: Jack Lau <[email protected]>
unique ssrc need to use unique srtp context, otherwise the server couldn't decrypted the rtx packet. move the "a=ssrc-group:FID" on top of SSRCs Signed-off-by: Jack Lau <[email protected]>
Signed-off-by: Jack Lau <[email protected]>
Signed-off-by: Jack Lau <[email protected]>
Signed-off-by: Jack Lau <[email protected]>
whip->buf size is 4096 rather than srtcp_len, srtcp data just use part of its memory, handle it need more logic. So allocate a temporary pkt to carry the SRTCP data Signed-off-by: Jack Lau <[email protected]>
need to be changed AV_LOG_DEBUG before official commit Signed-off-by: Jack Lau <[email protected]>
Signed-off-by: Jack Lau <[email protected]>
Signed-off-by: Jack Lau <[email protected]>
Signed-off-by: Jack Lau <[email protected]>
ghost
mentioned this pull request
JackLau1222
force-pushed
the
workflows
branch
2 times, most recently
from
1c20a98 to
487998b
Compare
JackLau1222
force-pushed
the
workflows
branch
2 times, most recently
from
2c40a5c to
80db6eb
Compare
RTP retransmission described in RFC4588 (RTX) is an effective packet loss recovery technique for real-time applications with relaxed delay bounds.
This PR provides a minimal implementation for RTX and RTCP NACK (RFC3940) and its associated SDP signaling and negotiation.