RTX + RED/FEC issue

[Sergio Garcia Murillo]

Hi all,

I was implementing RFC 4588 in my MCU to be in sync with latest changes
on Chrome but found an issue which I think should not be happening.

When you negotiate the RTX payload with Chrome, it only sends one
payload with the VP8 apt associated payload:

a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=rtpmap:96 rtx/90000
a=fmtp:96 apt=100

But if you start reporting packet lost at the receiver end, Chrome, in
some circumstances (I think it depends on available bandwidth +RTT),
starts sending RED/FEC packets. The issue is that when a packet is lost
and NACKED, the RTX packet arrives with a rtp payload type of 96 (rtx),
which has an associated payload type of 100 (vp8), regardless if it was
an VP8 or RED/FEC packet.

It think the only viable way of solving the issue is by adding a
secondary rtx payload associated to the red type, so the rtx packet is
reconstructed correctly.

a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=rtpmap:96 rtx/90000
a=fmtp:96 apt=100
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=116

For the record, I have always thought that the REF/FEC schema was
something quite clumsy and the FEC stream should have their own stream,
maybe using

https://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-04#section-6.1

Best regards
Sergio

P.S. Already opened an issue
https://code.google.com/p/webrtc/issues/detail?id=3948

[Sergio Garcia Murillo]

I was meaning https://tools.ietf.org/html/draft-singh-payload-rtp-1d2d-parity-scheme-00 ;)

[Harald Alvestrand]

I don't understand much of all these schemes, but what's the point in NACKing a RED/FEC packet?

Aren't they supposed to be just redundancy and forward error correction information?

--

--- You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Iñaki Baz Castillo]

2014-10-21 21:48 GMT+02:00 'Harald Alvestrand' via discuss-webrtc
<discuss...@googlegroups.com>:

> I don't understand much of all these schemes, but what's the point in
> NACKing a RED/FEC packet?
> Aren't they supposed to be just redundancy and forward error correction
> information?

As far as I understand NACK retransmissions are used to retransmit
loss packets within a SSRC (regardless their payload). If you send
VP8, FEC and RED on the same SSRC then you must be ready to receive
retransmissions of all those types.

--
Iñaki Baz Castillo
<i...@aliax.net>

[Stefan Holmer]

In this case I think the problem is that we offer rtx associated with vp8 on pltype 100, when in fact we're retransmitting red packets (pltype 116) since all packets are encapsulated in red. So the correct sdp should say:
a=fmtp:96 apt=116

Right?

/Stefan

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

[Sergio Garcia Murillo]

Hi Harald,

You are right that it doesn't make sense to rtx a RED packet, but as the packet is lost, you can't tell if the lost packet was VP8 or RED, so you have to NACK it anyway. That's why I am proposing to take a look at the FEC draft as it would allow to send the FEC packets in a different ssrc, and avoiding nacking RED/FEC packets.

Best regards
Sergio

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

[Sergio Garcia Murillo]

Hi Stefan,

I think that you should advertise both.

a=fmtp:96 apt=110
a=fmtp:97 apt=116

So when the receiver gets a rtx, it is able to know which payload was the original packet about.

I know, it is clumsy, but unfortunately it is how rfc 4588 works.. :(

Best regards
Sergio

[Stefan Holmer]

Why does the receiver need to know that? It could simply depacketize the rtx header and the red header and see what it is.

When we're using red all packets are encapsulated by a red header, the underlying packet can then either contain a ulpfec payload or a vp8 payload. Therefore I would imagine that retransmits would contain all three headers; rtx, red and vp8/fec. I think it would be strange to retransmit a packet with only rtx and vp8 headers.

It is a bit messy though, and I agree that fec on a separate ssrc is a lot cleaner.

[Sergio Garcia Murillo]

Well, if you are going to send the RTX with a RED packet regardless if it was originally an VP8 one, yes, that would work.

Best regards
Sergio

[Justin Uberti]

For RTCWEB, we are writing up guidelines on how to best do FEC, and will discuss SSRC handling specifically.

[Sergio Garcia Murillo]

Have not seen anything regarding FEC lately on rtcweb list, could you point me to the right place? I would be willing to collaborate.

[Sergio Garcia Murillo]

Hi Stefan,

I think having the FEC data on its own ssrc has major advantages, apart of getting rid of the RED payload completely.

Currently it is quite useless to have both RTX and FEC enabled simultaneously, as when you lost a packet you don't know if it was FEC or VP8 data. So, in case it was FEC, instead of just ignoring the drop as it was redundant data, you may nack it and wait for the data to be RTX. Even worst, as Chrome do not retransmit FEC data, so you may up waiting in your jitter buffer for a packet that will never arrive and end up asking an PLI/FIR. So the only solution so far, is completely disable the RTX as soon as you see FEC data coming..

Having FEC on a separate stream would avoid this issue, and probably have some other benefits in BWE. And also, we already have the complexity of handling several ssrcs for same media stream with RTX.

While the current FEC RFC 5109 explicitly forbids it, making it mandatory for the media and FEC streams to have same ssrc, in the ssrc-group RFC it implicitly allows it with the definition of the "FEC" group, as you can only have different ssrcs values in the ssrc lists.

   The <semantics> parameter is taken from the specification of the
   "group" attribute [RFC3388].  The initial semantic values defined for
   the "ssrc-group" attribute are FID (Flow Identification) [RFC3388]
   and FEC (Forward Error Correction) [RFC4756].

So, from an SDP perspective it would be quite "simple":

m=video 52406 RTP/SAVPF 100 116 117 96
a=ssrc-group:FID 975588630 1775248547
a=ssrc-group:FEC 975588630 1234567890
a=ssrc:975588630 cname:2@1-211b71f6-a9c7-4a30-8b26-730c42ece0c2
a=ssrc:975588630 mslabel:1-211b71f6-a9c7-4a30-8b26-730c42ece0c2
a=ssrc:975588630 msid:1-211b71f6-a9c7-4a30-8b26-730c42ece0c2 v0
a=ssrc:975588630 label:1-211b71f6-a9c7-4a30-8b26-730c42ece0c2v0
a=ssrc:1775248547 cname:2@1-211b71f6-a9c7-4a30-8b26-730c42ece0c2
a=ssrc:1775248547 mslabel:1-211b71f6-a9c7-4a30-8b26-730c42ece0c2
a=ssrc:1775248547 msid:1-211b71f6-a9c7-4a30-8b26-730c42ece0c2 v0
a=ssrc:1775248547 label:1-211b71f6-a9c7-4a30-8b26-730c42ece0c2v0
a=ssrc:1234567890 cname:2@1-211b71f6-a9c7-4a30-8b26-730c42ece0c2
a=ssrc:1234567890 mslabel:1-211b71f6-a9c7-4a30-8b26-730c42ece0c2
a=ssrc:1234567890 msid:1-211b71f6-a9c7-4a30-8b26-730c42ece0c2 v0
a=ssrc:1234567890 label:1-211b71f6-a9c7-4a30-8b26-730c42ece0c2v0
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 nack
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 goog-remb

a=rtpmap:117 ulpfec/90000
a=rtpmap:96 rtx/90000
a=fmtp:96 apt=100

Note that we are removing RED and keep apt to VP8 as the media stream will only contain VP8 packets now.

Best regards
Sergio

[Stefan Holmer]

I agree that having FEC on a separate SSRC would be nicer. We'll see what the outcome of the rtcweb discussions on this is.

/Stefan

[Justin Uberti]

This is what I am advocating in https://datatracker.ietf.org/doc/draft-uberti-rtcweb-fec/?include_text=1.

[Justin Uberti]

https://datatracker.ietf.org/doc/draft-uberti-rtcweb-fec/?include_text=1

[Sergio Garcia Murillo]

Hi Justin,

Awesome!

I still see the same problem than with RTX about the ussage of the ssrc-group attribute, that we are not able just by looking at the SDP to differentiate the ssrc from the media flow from the ssrc from the media flow. Maybe the usage of the a=ssrc:<ssrc> fmtp:<format> as already proposed on the list may help.

Also, I think that in the network chapter 7, adaptive usage of FEC, we should liaise with the rmcat group and reference their work here. I found this document particularly relevant:

http://datatracker.ietf.org/doc/draft-singh-rmcat-adaptive-fec/?include_text=1

Best regards
Sergio

[Justin Uberti]

Can you point me at the message where a=ssrc:x fmtp:y was proposed?

[Sergio Garcia Murillo]

I think that the thread started here:

http://www.ietf.org/mail-archive/web/rtcweb/current/msg13220.html

Best regards
Sergio

[Jeremy Noring]

On Wednesday, October 22, 2014 5:30:56 AM UTC-6, Sergio Garcia Murillo wrote:

Having FEC on a separate stream would avoid this issue, and probably have some other benefits in BWE. And also, we already have the complexity of handling several ssrcs for same media stream with RTX.

There's also benefits for MCUs; with the RED payload, it forces an MCU to do some sort of packet inspection on everything coming through to determine if it's VP8 or FEC, and that gets pretty inefficient.  Client software for WebRTC doesn't have to consider this, but with an MCU, it could potentially be doing packet inspection on hundreds or even thousands of concurrent streams.