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

[Marshall Eubanks <[e-mail]>]

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

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

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

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