Re: [AVT] [Fecframe] Timestamps issue in Draft "RTP Payload format for 1-DInterleaved Parity FEC"

Hi Magnus,

Comments are inline. 

> -----Original Message-----
> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] 
> Sent: Friday, September 12, 2008 11:44 AM
> To: Ali C. Begen (abegen)
> Cc: Guy Bonneau; fecframe@ietf.org; IETF AVT WG
> Subject: Re: [Fecframe] Timestamps issue in Draft "RTP 
> Payload format for 1-DInterleaved Parity FEC"
> 
> Ali C. Begen (abegen) skrev:
> > You are correct. Note that the 1-D draft is adopting SMPTE 
> 2022-1 spec 
> > and fixing the RTP issues with it. The SMPTE spec does not use the 
> > timestamp field at all (receivers ignore it and what the 
> sender puts 
> > in that field is undefined). In our draft, we use it and 
> set it as you 
> > described below.
> > 
> > The motivation for this change from 2733 is that the clock at the 
> > instant the fec packet is transmitted is not a very useful 
> information.
> > It does not help in FEC decoding process, either. 
> Furthermore, unlike 
> > the source RTP packets, FEC packets don't have a 
> synchronization issue.
> > So their transmission time is not very critical (as long as they 
> > arrive on time for FEC decoding).
> > 
> > Instead, during our discussions, we decided to set it 
> differently. Of 
> > course, FEC packets identify which source packets they 
> protect (based 
> > on the SN base, L, D). However, if the FEC packet is 
> received earlier 
> > than the source packets it protects (might be the case), by 
> checking 
> > the timestamp field, we can now know the timestamp of the earliest 
> > source packet that is protected by this packet (in addition 
> to its seqnum).
> > This is a useful information. Or, if that earliest source 
> packet won't 
> > arrive (i.e., it is lost), we will know by when we have to 
> recover it.
>  >
> > OTOH, if the source packets are received earlier than the 
> FEC packet, 
> > the timestamp info would not be that useful.
> > 
> > We can think of it as follows as well: The FEC packet has some 
> > information from that earliest source packet. That source 
> packet was 
> > sampled at time say, t, so, it makes sense to put the value of t in 
> > the timestamp field of the fec packet.
> > 
> > (RFC 3550 says that "The timestamp reflects the sampling instant of 
> > the first octet in the RTP data packet.")
> 
> The problem with this definition is that you are completely 
> screwing up the RTCP jitter calculation. Sure, RTCP jitter 
> calculations are screwed up by some other RTP payload 
> formats, like video with multiple packets for the same frame. 

We are not touching the jitter measurement for the source packets. But, yes, our setting will disable the jitter measurement for the FEC packets.

> However, there is a trade-off here. I am not certain that the 
> timestamp of the source packet are that useful as you anyway 
> have an explicit reference to the packets you will need. If 
> the SN base packet hasn't arrived, then the repair packet is 
> early. Not particular likely unless strange transport 
> reordering mechanisms are in place. If as you say the repair 
> packet arrives after SN base source packet, then you can look 
> up the corresponding timestamp.

Agree.

> So in this case, I don't see how loseing the possibility use 
> the RTCP jitter for something useful on the FEC stream is 
> motivated. And if the FEC stream jitter measurements works 
> decently, then they can be used to cover for source streams 
> that aren't able to utilize the jitter measurement.

I don't think jitter measurements based on the FEC packets could be effectively used for estimating the jitter for the source packets. There are several different sending arrangements adopted for sending the FEC packets that will mess up the measurements anyway. Furthermore, the repair packets might be sent over a different network, qos class, etc.

But, why do you need something like this in the first place? We can measure the jitter in the source stream itself.

> I think we should include AVT in RTP related discussions. I 
> also need to add this bit of information to the RTP payload how to.

Agree. Thanks for the note.

-acbegen

> Cheers
> 
> Magnus Westerlund
> 
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Färögatan 6                | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
> 
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt