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

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

> abegen: 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.
> 
> anand: On the contrary I believe that any FEC Scheme that is capable of protecting multiple source flows together must not
> rely on sequence numbers (RTP/Self-assigned seq no./Generic Source Payload ID in its current form). It should use Payload
> IDs containing Source Block Numbers and ESIs so that the Encoding Symbols can be placed correctly at the decoder/reciever.

This is up to the designer of the code. If you wanna modify the source packets, feel free to but be aware of its implications.
 
> abegen: 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.
> 
> anand: I agrees that re-sequence numbering is possible. But this has limited use as the problems arise at the client. A Source
> Packet can not have the same sequence number (RTP/Artificial Seq No.) for multiple FECFrameworks simply because the
> sequence number sequence(assumed to be incremental by 1) will overlap with another such running sequences for other
> flows.
> Example:
> Let us assume that we resequence the F1 Source Packets as 1,2,3 and feed them to FEC1 and FEC2. Now, FEC2 resequences
> the F2 Source Packets as 4,5,6. In this way we have two Source Blocks, one each for FEC1 and FEC2. Now when we get the
> next set of Source Packets for F1 we can reseqnum them as 4,5,6 for FEC1 but not for FEC2. One can think of using different
> sequence numbers for the same flow for different frameworks. But then this information (one new sequence number for
> each framework) must be attached to the Source Packet, otherwise the decoder will not be able to place the Source Packets.

Resequencing is something I mentioned if you wanted to turn multi-input into a single input. This does not relate to fecframe so we don't discuss it in the framework draft. Also after FEC is done, you need to de-sequence all those input streams somehow. That is also something we don't discuss within 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.
> 
> abegen: 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.
> 
> 
> anand: I think this will not work as you might attach in the repair payload IDs the (FlowID,ISN) combination for each of the
> flows. However the information about the position of each Source Packet is still not there as this information only tells the
> ISN for each flow, but does not tell how the Source Packets from multiple flows have been placed together to form the
> Source Block at the encoding FECFramework.

I think you are dismissing the fact that not everything is carried in band, meaning that we have something called configuration information. 

Again, modifying the source packets in the way you would like to is not illegal, but unless absolutely necessary, pretty much nobody does it.
  
> >  > 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.
> 
> abegen: 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).
> 
> anand: My motive behind opening this discussion was to discuss if we can define a generic payload id that can be also used
> for the cases such as LA-FEC. Such cases are not outside the scope of FECFramework but I think currently we do not have a
> formally defined way of handling them. I think such a Source FEC Payload ID must combine the Source FEC Payload IDs of the
> individual FEC schemes that have been used to encode the Source Packet.

If different schemes use different payload IDs for the source packets, it won't work. If you wanna change the content of the generic payload ID, I am still not seeing the need for it.

-acbegen