Why RED is supported?
2,246 views
Skip to first unread message
Mamadou
Apr 20, 2012, 4:27:50 PM4/20/12
to discuss-webrtc
Hi all,
I'm using Chrome Canary v20.0.1111.0 and I've a question about support
for Redundant data as per RFC 2198.
Chrome always include RED in its SDP (rtpmap:101 red/90000) for the
video media when negotiating a session. When using two Chromes, the
common codecs will be VP8, ULPFEC and RED. Checking the RTP packets we
can see that chrome only send RED packets encapsulating VP8 payload
and no VP8 packets are sent. The issue here is that there is no
redundancy at all as no VP8 packet is sent. In all case, if I'm not
wrong, it's not possible to send redundant packets when SRTP is used
(which is mandatory for WebRTC) as the sequence number cannot be
duplicated as it's authenticated (see RFC 3711 section 3.1).
At the end of the history, we have RED packets with extra header
without any benefit.
I'm I missing something?
Regards,
I'm using Chrome Canary v20.0.1111.0 and I've a question about support
for Redundant data as per RFC 2198.
Chrome always include RED in its SDP (rtpmap:101 red/90000) for the
video media when negotiating a session. When using two Chromes, the
common codecs will be VP8, ULPFEC and RED. Checking the RTP packets we
can see that chrome only send RED packets encapsulating VP8 payload
and no VP8 packets are sent. The issue here is that there is no
redundancy at all as no VP8 packet is sent. In all case, if I'm not
wrong, it's not possible to send redundant packets when SRTP is used
(which is mandatory for WebRTC) as the sequence number cannot be
duplicated as it's authenticated (see RFC 3711 section 3.1).
At the end of the history, we have RED packets with extra header
without any benefit.
I'm I missing something?
Regards,
Magnus Flodman
Apr 23, 2012, 4:17:13 AM4/23/12
to discuss...@googlegroups.com
When you use FEC we use RED to encapsulate the payload (in this case
VP8) and FEC. The whole stream will look like one RED stream
independent on the level of FEC protection. Hence when FEC is enabled
we will add the RED header to all packets even if FEC is currently not
used. FEC can be "on" for a fraction of frames (packets) or "on" for
all frames. This is determined by the importance of the frame and
packet (as an example the packets of a key frame is most important a
packet to an enhancement temporal layer is nice to have but not
important for the stream)
The only way to know if the packet is FEC or VP8 is to look direct
after the RTP header, where the RED header is located.
Since the stream look like a normal RTP stream where RED is the
payload type and all packets come in sequence without gaps there is no
issue to use SRTP.
VP8) and FEC. The whole stream will look like one RED stream
independent on the level of FEC protection. Hence when FEC is enabled
we will add the RED header to all packets even if FEC is currently not
used. FEC can be "on" for a fraction of frames (packets) or "on" for
all frames. This is determined by the importance of the frame and
packet (as an example the packets of a key frame is most important a
packet to an enhancement temporal layer is nice to have but not
important for the stream)
The only way to know if the packet is FEC or VP8 is to look direct
after the RTP header, where the RED header is located.
Since the stream look like a normal RTP stream where RED is the
payload type and all packets come in sequence without gaps there is no
issue to use SRTP.
Mamadou
Apr 23, 2012, 5:20:31 AM4/23/12
to discuss-webrtc
This is what we expected but not what's seen. Both RED and FEC are
correctly negotiated but no FEC packets are included in RED blocks. We
are calling chrome from our own client not built with WebRTC stack and
this is why I know that there is no FEC packets.
There is no relation but I think that it could be interesting to allow
NULL encryption in the beta phase for debugging RTP/RTCP.
Another question: Is Reed-Solomon codes supported?
correctly negotiated but no FEC packets are included in RED blocks. We
are calling chrome from our own client not built with WebRTC stack and
this is why I know that there is no FEC packets.
There is no relation but I think that it could be interesting to allow
NULL encryption in the beta phase for debugging RTP/RTCP.
Another question: Is Reed-Solomon codes supported?
Magnus Flodman
Apr 23, 2012, 7:57:45 AM4/23/12
to discuss...@googlegroups.com
We will only send FEC packets when there is packet loss.
Reed-Solomon is not supported.
-Magnus
Mamadou
Apr 23, 2012, 8:42:31 AM4/23/12
to discuss-webrtc
How could you know that there are packet loss? The remote peer don't
send RTCP-NACK.
send RTCP-NACK.
Harald Alvestrand
Apr 23, 2012, 10:14:42 AM4/23/12
to discuss...@googlegroups.com
On Mon, Apr 23, 2012 at 14:42, Mamadou <bos...@yahoo.fr> wrote:
> How could you know that there are packet loss? The remote peer don't
> send RTCP-NACK.
> How could you know that there are packet loss? The remote peer don't
> send RTCP-NACK.
Does it send RTCP-RR?
Mamadou
Apr 23, 2012, 11:04:39 AM4/23/12
to discuss-webrtc
Yes at the start of the stream (nothing to report) as it's mandatory
as per RFC 3550. The subsequent RTCP packets are sent using SR.
On Apr 23, 4:14 pm, Harald Alvestrand <h...@google.com> wrote:
as per RFC 3550. The subsequent RTCP packets are sent using SR.
On Apr 23, 4:14 pm, Harald Alvestrand <h...@google.com> wrote:
Reply all
Reply to author
Forward
0 new messages