[FECFRAME-PROTO] Fwd: Flexible FEC grouping and associations

[Marshall Eubanks <[e-mail]>]

In case you didn't get this directly.

Marshall

Begin forwarded message:

> From: "Ali Begen (abegen)" <[e-mail]>
> Date: January 30, 2008 4:53:09 PM EST
> To: <[e-mail]>
> Cc: <[e-mail]>, "Greg Shepherd" <[e-mail]>,  
> "Marshall Eubanks" <[e-mail]>, <[e-mail]>,  
> <[e-mail]>
> Subject: 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-PROTO mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/fecframe-proto