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

[Magnus Westerlund <[e-mail]>]

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

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 think we should include AVT in RTP related discussions. I also need to 
add this bit of information to the RTP payload how to.

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