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

[Vincent Roca <[e-mail]>]

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).


> *** 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.

Cheers,

   Vincent