Re: [Fecframe] request for pub draft-ietf-rtp-raptor-04

["Luby, Michael" <[e-mail]>]

Comments below.
Cheers, Mike


On 3/23/11 1:44 AM, "Vincent Roca" <[e-mail]> wrote:

> Hello Mike,
> 
>> *** There seems to be a couple of ways to solve this.  One, as you suggest,
>> is to mandate that the solution must have all source packets arrive at the
>> FEC encoder.  Another way is to have logic at the FEC encoder that detects
>> if there are missing packets (easy to do in this case because of the RTP
>> sequence numbers), and if so, for FEC encoding purposes (not transmission
>> purposes), creates a dummy packet of all zeroes for each missing sequence
>> number (or whatever the receiver is going to interpret as a valid packet but
>> with no real audio/video info inside), and encode the source block including
>> the dummy packet(s).  Probably best to point out the problem and then
>> mention some possible ways to solve it.
> 
> I agree, let's point the issue first and then suggest a few ways to fix
> or mitigate it. Which solution to prefer depends on the use-case.
> This is already discussed in version -14 of the framework I-D
> (section 10.2):
> ---
>        In this case,
>        another solution SHOULD be considered that is use-case specific
>        and whose consequences need to be carefully considered (e.g., by
>        duplicating the last ADU received before the loss, or by inserting
>        a zero'ed ADU, depending on the ADU flow nature).
> ---
> 
> However inserting a dummy source packet and not sending it
> means it will be considered as erased at the FECFRAME decoding,
> which impacts the recovery capabilities of the FEC scheme.
> And we have no way to signal to the receiver this is a dummy
> source packet.
> 
> So there are two good reasons such erasures do not happen
> too often:
> 1) because a missing audio/video source packet impacts the
>      perceived quality,
> 2) because it also impacts the FEC protection of source packets
>      that are considered by the FECFRAME encoder.
> 
> An alternative is of course to send such dummy source packets
> of signal them to the receiver (not feasible with current specs).
*** There is no benefit of sending the dummy source packets that I can see,
as they don't contain any information that can help the receiver.  The rest
seems ok.
> 
> 
>> *** It should be noted that in any system where not all the source packets
>> containing video/audio data get to the FEC encoder is pretty badly designed,
>> as no matter how you overcome it, you are still going to be missing
>> video/audio at all the clients that receive the stream.  At least if you
>> have RTP sequence numbers in the source packets you will know this at the
>> FEC encoder (may not be true of other solutions, i.e., it may even be hard
>> to detect that not all the video/audio source packets get to the FEC
>> encoder, and this probably should be pointed out for other solutions).
> Good point. However I guess there are other means to identify
> missing ADUs within the upper application, even if it's not
> visible at FECFRAME level.
*** Not always true.   For example, using MPEG2-TS format (pretty typical
for broadcasters where this technology might be deployed) doesn't have any
real easy to extract a unique packet identifier at the FEC sender to verify
that there isn't any packet loss, and thus at the very least there would
have to be a pretty deep packet inspection at the FEC sender to determine if
there are missing source packets.
> 
> Cheers,
> 
>    Vincent