Subject: [MMUSIC] Flexible FEC grouping and associations

From: "Ali Begen (abegen)" <[email-masked]>
Date: Wed, 30 Jan 2008 13:53:09 -0800

Hi everyone,

In Vancouver, we gave a brief introduction on this issue in MMUSIC and
the chairs asked us to examine the existing drafts/RFCs before going any
further.

In yesterday's FECFRAME design team meeting, we discussed this topic and
concluded that in terms of what we would like to support in FECFRAME,
existing RFCs/drafts were not helping us much. We examined RFC 3388, RFC
4756, and draft-ietf-mmusic-decoding-dependency-00. 

Here is the summary.

We would like to support the following:
1- A source flow MAY be protected by multiple FEC schemes
2- An FEC scheme MAY generate multiple repair flows
3- Source flows MAY be grouped prior to FEC protection (One or more
repair flows can protect a group of source flows)

The Grouping/Association Problem:
RFC 3388 states that an "m" line identified by its "mid" attribute MUST
NOT appear in more than one "a=group" line using the same semantics. So,
the FEC grouping semantics (RFC 4756) requires us to put every source
and repair flow in one "group:FEC" line. This is severely limiting as it
becomes difficult to associate the source flows with the repair flows,
and/or group them. 

Does anybody remember what the main reason was for this requirement?

A very simple example:
Source #1: Base-layer video
Source #2: Enhancement-layer video
FEC Scheme #1: Produces Repair #1 that protects Source #1, and Repair #2
that protects the group of Source #1 and #2 

RFC 3388 requires us to say
a=group:FEC S1 S2 R1 R2, 

However, this does not say anything about which repair flow(s) is
protecting which source flow(s). A new generalized grouping attribute
("a=gengroup") would help this problem by allowing an "m" line to appear
multiple times in the same grouping semantics. Then, we could write

a=gengroup:FEC S1 R1 
a=gengroup:FEC S1 S2 R2

However, we do need additional mechanisms for:

The Additivity Problem:
We would like to support additive repair flows (multiple repair flows
can be decoded jointly to improve decoding rate). Note that we don't
need layered dependency among the repair flows. Source flows might be
layered encoded, but we don't think layered encoded FEC streams are much
of use.

Currently, there is no support for additivity from existing documents.
decoding-dependency draft offers "mdc" dependency relation, however, (i)
using the keyword "mdc" is not very suitable for FEC, and (ii) the draft
is only intended for RTP flows.

The Prioritization Problem:
We would like to support prioritization of the repair flows. The sender
can assign different priorities to different repair flows and we require
the receivers to act accordingly. However, there is no support for
prioritization from existing documents.

One option is of course to define new stuff specific to our needs in the
FECFRAME WG, however, we believe it is for everybody's benefit to
coordinate this effort with MMUSIC and address these issues in a more
general way as they may be required by other frameworks/applications. 

We would like to get everybody's opinion on this issue.

Thanks,
-acbegen

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Thomas Schierl" <[email-masked]>
Date: Thu, 31 Jan 2008 18:42:10 +0100

Hi Ali,

One comment, we think that layered FEC does make sense. There may be future
applications, which code the media and the FEC in a layered fashion.

You may be right that from the current viewpoint layered FECs may not be of
much use.  But currently no one is using layered codecs. That may change,
since there is now an efficient scalable codec for video. And in that case,
your assumption may not hold.

So, why not supporting this additional feature?

Thomas

> -----Original Message-----
> From: Ali Begen (abegen) [mailto:[email-masked]]
> Sent: Wednesday, January 30, 2008 10:53 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: [Fecframe] Flexible FEC grouping and associations
>
> Hi everyone,
>
> Fecframe mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/fecframe

----
Visit us at

GSMA Mobile World Congress / Barcelona, Spain / 11 - 14 February 2008 / Broadcast Mobile Convergence Forum / Booth 2B82
http://www.mobileworldcongress.com/homepage.htm

OFC 2008 / San Diego, California, USA / 26 - 28 February 2008 / Booth 411/415
http://www.ofcnfoec.org

---

From: Mark Watson <[email-masked]>
Date: Thu, 31 Jan 2008 10:14:10 -0800

Thomas,

What do you actually mean by "layered FEC" ?

Certainly there is a concept of multiple FEC layers which makes sense, and
in fecframe we have discussed this. This is what Ali refers to below as
additivity - where multiple FEC streams can be usefully decoded in
combination.

However it's a very different concept from layering in the sense of a
layered video codec. In SVC, you absolutely need the base layer in order to
make sense of the enhancement layer. This is not (cannot!) be true for FEC
"layers" because the whole point of FEC is to deal with losses - the
possibility of the "base layer" packets being lost must be accepted. The
"enhancement layer" is thus useful on its own.

Put another way, there can be no "dependency" between FEC layers and this is
why we thought it would not be correct to use the layer option in your
dependency draft for FEC.

In fact FEC "layers" are closer in concept to MDC, but this does not capture
the point that, despite the absence of dependency, there may still be a
notion of preference amongst the layers.

There is of course a notion of dependency between source flows and an FEC
repair flow that protects them.

...Mark

On 1/31/08 9:42 AM, "Thomas Schierl" <[email-masked]> wrote:

> GSMA Mobile World Congress / Barcelona, Spain / 11 - 14 February 2008 /
> Broadcast Mobile Convergence Forum / Booth 2B82