Subject: [Fecframe] Flexible FEC grouping and associations

From: "Ali Begen (abegen)" <[email-masked]>
Date: Tue, 5 Feb 2008 16:24:34 -0800

So far, nobody has commented on the main issue we are facing: the
flexible grouping of source and repair flows.

Let me restate our problem with a more direct question.

Should we define a new grouping attribute that will not have the
restrictions RFC 3388/4756 have? This flexibility may even help with the
decoding-dependency draft. The current draft allows only layered or mdc
dependency in one DDP group. Don't you think this might be restrictive
in the future, if it is not already?

Any strong feelings for doing or not doing this? Please share your
comments. Don't forget to CC [email-masked].

Thanks,
-acbegen

-----Original Message-----
From: Ali Begen (abegen) 
Sent: Wednesday, January 30, 2008 1:53 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [Fecframe] Flexible FEC grouping and associations

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

_______________________________________________
Fecframe mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/fecframe
_______________________________________________
Fecframe mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/fecframe