Re: [Fecframe] Comments aboutdraft-galanos-fecframe-rtp-reedsolomon-00

[Vincent Roca <vincent.roca at inrialpes.fr>]

Me again.

> > * Section 6.2.2: Back to the idea of removing the constraint on
> > consecutive
> > source packets, I'm wondering if the following FEC header format
> > wouldn't be
> > okay:
> >
> >  0                   1                   2                   3
> >  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |          Base SN              |           Max SN              |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |    Source Block Length (k)    |   Enc. Symbol ID (16 bits)    |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> > Thanks to this FEC header:
> > - We know that all SN values in {Base SN..Max SN} are included in this
> >   source block.
> > - We know their actual number (k) even if some of RTP SN are missing.
> > - We know the ESI of the FEC repair packet (in {K, N-1}), no matter the
> >     
> >   GF m parameter since it's 16-bit long.
> > - And we know in which order incoming source RTP packets should be
> >   stored in the block, even if there are gaps in the SN.
> > At a receiver, the actual SN value in the RTP header of an erased
> > source packet is anyway recovered along with the rest of the
> > header/payload
> > so there's no problem either.
> > [Einat] This is interesting. Do you mean that all RTP packets in the
> > range [Base SN...Max SN] will be included in this block?
> > If not then the receiver will know for sure if he can recover a lost
> > packet only after making the decoding operation on the relevant block.
> > This could lead to unnecessary decoding calls.
> > See my comment above regarding the need for signaling N-K for each FEC
> > block.
> >   
> >     
> => VR: my above proposal is not sufficient! It won't help identifying 
> the position of source
> packets inside the source block.
>
> However, I think there's a solution to the case where there's a limited 
> number of erasures
> prior to FECFRAME. Instead of carrying a bit mask that identifies which 
> source packet
> of a SN range are actually considered or not, I suggest to replace 
> erased source packets
> by zero'ed symbols.
> These symbols will be reconstructed by the receiving side FECFRAME, and 
> a quick
> check will enable him to get rid of them immediately (there's no RTP 
> header, it's all zero).
>
> To answer your question: yes, all the packets in [Base SN; Max SN] are 
> in the block,
> except that some of them are "fake" packets (zero'ed) which means they 
> are easily
> recognized.
> [Einat] If I understand what you suggest then increasing the source
> block size as you proposed will increase encoding/decoding complexity.
> So there's a tradeoff to consider here.
>   

=> VR: of course, there's a tradeoff since the block size increases and the
receiver needs to decode "fake" source packets... It takes time and CPU
cycles. But as I said, it can make sense if there are a limited number of
erasure. So let's clarify the possibilities:

- no erasure prior to FECFRAME => no waste if we follow the
 [Base SN; Max SN] scheme.
 NB: we can also use your scheme as proposed in the I-D, of course,
 but there's a "universal" solution so let's take advantage of it.

- a limited number of erasures => use "fake" source packets. The block size
 can be large, there's no penalty in terms of transmission overhead, 
it's simple.
 On the downside, there's some extra processing required, hence the
 recommended limit to situations where there are few erasures. However
 it will also work on other situations ;-)

- a high number of erasures, or situations where CPU is the limit rather
 than the transmission overhead => use mask techniques to deal with gaps
 in the RTP sequence numbering (i.e. source packets erased before reaching
 FECFRAME).

Does it make sense? Did I miss something?
Cheers,

  Vincent