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

[David R Oran <[e-mail]>]

I tend to agree with Marshall's comments below. A couple of more  
things embedded.

On Sep 15, 2008, at 4:46 AM, Marshall Eubanks wrote:

> Hello;
>
> On Sep 12, 2008, at 11:56 AM, Ali C. Begen (abegen) wrote:
>
>> Hi Magnus,
>>
>> Comments are inline.
>>
>>> -----Original Message-----
>>> From: Magnus Westerlund [mailto:[e-mail]]
>>> Sent: Friday, September 12, 2008 11:44 AM
>>> To: Ali C. Begen (abegen)
>>> Cc: Guy Bonneau; [e-mail]; 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.
>>
>
> I would disagree with this. Precisely because you might send the FEC
> packets differently, it would be useful to
> know their time delay & jitter. Suppose you put FEC packets in a QOS
> class that causes them to sometimes arrive too late, because of
> buffering or path differences. How would I be able to troubleshoot
> that at the receiver if they
>
In fact, if anything differs about the 5-tuple in the IP header, not  
just the DSCP, the packets might get routed differently. This of  
course inclues the case where the FEC is sent to a separate multicast  
group.

> - all have a timestamp a few 100 milliseconds or more too early (the
> lowest sequence number means a large delay) and
> - will likely have jumps in this time stamp delay  due to, e.g.,
> dropped frames in the encoder ?
>
> However, there could be FEC schemes where the original clock is not
> available (i.e., middleware FEC). So,
> maybe the text should be
>
> The timestamp MUST be set to the value of the media RTP clock at the
> instant the FEC packet is transmitted, if the media RTP clock is
> avalable to
> the sender of the FEC packets. If the media RTP clock is not available
> to the sender of the FEC packets, the timestamp MUST be set to the
> value of a parallel RTP
> clock maintained by the sender, and this RTP clock SHOULD be
> synchronized with the
> media RTP clock.
>
This works for me.

DaveO.
> Note that the SMPTE spec is silent here, so they are not a issue.
>
> Regards
> Marshall
>
>
>
>> 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 [phone]
>>> Färögatan 6                | Fax   [phone]
>>> S-164 80 Stockholm, Sweden | mailto: [e-mail]
>>> ----------------------------------------------------------------------
>>>
>> _______________________________________________
>> Fecframe mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/fecframe
>
> _______________________________________________
> Fecframe mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/fecframe

_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www.ietf.org/mailman/listinfo/avt