Re: [Fecframe] About the Generic Explicit Source FEC Payload ID

["Ali C. Begen (abegen)" <[e-mail]>]

>  > In such cases even when the Source Packet flows are RTP flows we must
> add Source Packet Payload IDs. In addition we can
>  > not use the Generic Explicit Source FEC Payload ID as it is described
> in Section 5.3.1 of the FEC Framework Draft because the
>  > position of a Source Packet in the Source Block will not be unique
> across all FEC Schemes.
> 
> abegen: Sorry, I don't understand this. The place of a source packet is
> derived from the information put in the repair packets, not source packets.
> 
> anand: I was of the opinion that the Source Packet's place is derived
> from the information put in the Repair Packets only when they belong to
> a single sequenced flow. In this case the Repair FEC Payload ID carries
> the Initial Sequence Number which is used to place the Source Packet in
> its place. In other cases where the Source Packets are not sequenced or
> they belong to multiple arbitrary sequenced flows I believe the Source
> Packet's place is calculated using the information present in the Source
> Payload ID, such as Source Block Number and Encoding Symbol ID(ESI). I

Note that not every FEC scheme is capable of protecting multiple source flows together since their repair payload IDs are only designed for a single sequenced source flow. If an FEC scheme wants to be able handle such scenarios, it needs to be designed that way.

One could put the multiple source flows and re-seqnum them outside the fecframe and then feed the resulting stream into the fec encoder. And yes, then the original seqnums (such as RTP seqnums) cannot be used. But, this has nothing to do with fecframe's capability of protecting multiple source flows together. Because, here you are still feeding a single flow into fecframe.

> think that is how the Raptor Schemes for DVB AL-FEC are designed. Also
> "draft-roca-fecframe-simple-rs" defines one such FEC Scheme for Reed
> Solomon codec where a FEC Source Packet MUST contain the specified
> Source FEC payload ID.
> 
> abegen: It should be sufficient to have the source packets seqnum'ed.
> And RTP satisfies that requirement nicely.
> 
> aanand: When we mix two RTP flows we loose the unique sequence number
> sequences which would have been otherwise used by the FECFrameworks at
> the sender and the receiver to place Source Packets. This problem
> together with my opinion above makes it difficult to use the Generic
> Explicit Source FEC Payload ID which is based on sequence numbers that
> are unique across the FECFrameworks.
> For example:
> Lets continue the example with flows F1, F2 and frameworks FEC1, FEC2.
> We add the following assumptions:
> FEC1 uses Source Blocks of length 3 and FEC2 of length 6.
> RTP sequence numbers for F1: 1,2,3
> RTP sequence numbers for F2: 3,4,5.
> I think RTP sequence numbers or any unique "consecutive/"/ sequence
> numbers across all FECFrameworks can not be used to place the Source
> Packets in the Source Block for FEC2, so we must add Source FEC Payload
> IDs.
> 
> Maybe I am missing some points, in that case I apologize for my ignorance.

You could use an identifier for your source flows and this will allow you to use their original seqnums. And in the repair payload IDs, you could use those identifiers.
 
>  > Another observation regarding the Generic Explicit Source FEC Payload
> ID, since it does not contain the Source Block Number
>  > and relies solely on consecutive sequence numbers it seems that the
> corresponding Repair FEC Payload IDs must also use the
>  > Initial Sequence Number of each Source Block instead of the Source
> Block Number.

Yes. However, if the fec scheme used source block number info during encoding, that means it added source fec payload IDs to reflect that number (i.e., it has modified the source packets and it did not use the generic payload id).
 
> abegen: The generic field cannot carry the source block number as you
> said block sizes can and will vary among fecframe instances. And source
> block number is something used by the decoder but it is derived from the
> seqnum and base seqnum of a block (i.e., its value is not really used in
> an absolute fashion). I am not sure whether you saw something in the
> text that said otherwise.
> 
> aanand: It was just an observation because it means that some FEC
> Schemes which explicitly mention a Source FEC Payload ID, Repair FEC
> Payload ID combination not based on sequence numbers will not be usable
> in the use cases of interdependent FECFrameworks. And if my points above
> are correct we might not be able to use unique sequence numbers to place
> Source Packets across all the interdependent FECFrameworks.

-acbegen