Subject: [AVTCORE] RTP/TFRC + FEC ?

From: Olivier Crête <[email-masked]>
Date: Fri, 06 May 2011 20:51:50 -0400

Hi,

I've implemented the RTP/TFRC draft and it seems to work pretty well.
That said, it also introduces some level of packet losses. Also, with
some wifi connections, we have a relatively high rate of non-congestion
packet loss. For both of these cases, I'd like to implement some kind of
FEC, since losing a single packet tends to give nasty artifacts with
video (especially using the free video codecs).

It seems the current tendency in recent RFCs related to FEC is to send
the FEC data as a separate stream from the main data. This seems to go
against the intent of RTP/TFRC since using a second stream may
effectively double the bandwidth share used by the video. Mixing both
the video packets and the FEC packets in the same stream seems like a
better idea to me for the unicast use-case. Is anyone implementing such
an approach? Is there any standard around that? Or am I missing
something?

-- 
Olivier Crête
[email-masked]

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sat, 7 May 2011 11:47:07 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Olivier Crête
> Sent: Friday, May 06, 2011 8:52 PM
> To: [email-masked]
> Subject: [AVTCORE] RTP/TFRC + FEC ?
> 
> Hi,
> 

That has a lot good features. Please see the drafts in fecframe wg. The fec framework draft will also tell you that both the source and fec packets can be sent in their own RTP streams (with different SSRCs) but within the same UDP flow, if that is what you are worried about.

> effectively double the bandwidth share used by the video. Mixing both

Huh? It does not matter at all for the overhead whether you send the fec packets separately or in-band. Also, FEC does not need to double the bandwidth.

-acbegen

---

From: Olivier Crête <[email-masked]>
Date: Mon, 09 May 2011 10:34:29 -0400

On Sat, 2011-05-07 at 11:47 -0700, Ali C. Begen (abegen) wrote:
> That has a lot good features. Please see the drafts in fecframe wg.
> The fec framework draft will also tell you that both the source and
> fec packets can be sent in their own RTP streams (with different
> SSRCs) but within the same UDP flow, if that is what you are worried
> about.

I saw vague allusions to using different SSRCs, but I couldn't find
anything to signal that using SIP/SDP ?

> Huh? It does not matter at all for the overhead whether you send the
> fec packets separately or in-band. Also, FEC does not need to double
> the bandwidth.

It's not about overhead, it's about the fact that it will be two
streams, each with its own TFRC state. And with TFRC I would assume that
two streams would get roughly twice the bandwidth of one stream (and I
guess that's not appropriate).

Collabora Ltd

---

From: Olivier Crête <[email-masked]>
Date: Mon, 09 May 2011 12:47:03 -0400

> anything to signal that using SIP/SDP ?

Arg, I found a:ssrc-group.. seems like I'm not very good at reading.

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 9 May 2011 09:57:26 -0700

> From: Olivier Crête [mailto:[email-masked]]
> Sent: Monday, May 09, 2011 10:34 AM
> To: Ali C. Begen (abegen)
> Cc: [email-masked]
> Subject: RE: [AVTCORE] RTP/TFRC + FEC ?
> 

RFC 5576 will help with that.
 
> streams, each with its own TFRC state. And with TFRC I would assume that

Yeah but I'd imagine you would want to optimize your source and FEC bitrates somewhat jointly anyway. If your source rate is untouchable, then only your FEC rate will be variable. 

> guess that's not appropriate).

You are right that it is not appropriate but I don't see why TFRC would get roughly twice the bw of one stream if you use two TFRC states. You can easily apply the TFRC limit on the source+FEC, and then try to allocate that bw between the source and FEC.

-acbegen

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 10 May 2011 11:05:07 +0200

On 2011-05-09 18:57, Ali C. Begen (abegen) wrote:

>> two streams would get roughly twice the bandwidth of one stream
>> (and I guess that's not appropriate).
> 
> You are right that it is not appropriate but I don't see why TFRC
> would get roughly twice the bw of one stream if you use two TFRC
> states. You can easily apply the TFRC limit on the source+FEC, and
> then try to allocate that bw between the source and FEC.
> 

I think this is a comment that the TFRC draft authors should take to
heart that the document will need to have a discussion on how to
aggregate multiple SSRCs into a single TFRC flow state.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Olivier Crête <[email-masked]>
Date: Tue, 10 May 2011 10:19:07 -0400

> aggregate multiple SSRCs into a single TFRC flow state.

Actually, aggregating multiple SSRCs into one RTP/TFRC stream is
problematic as TFRC expects to have a linear sequence number. That means
we need to put a TFRC seqnum inside the RTP header extension, can't use
the RTP one. I noticed that Google is already doing something like that
in their we-like-standards-but-not-quite RTP/TFRC implementation in
Google Talk.