[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AVT] retransmission payload format



--> Magnus Westerlund writes:
...
>Using multiple payload types with different rates in the retransmission 
>stream and having the original timestamp in the RTP header forces the 
>RTP session of switching the rate also for the retransmission SSRC. And 
>the number of switches can potentially be several for each switch in the 
>original stream. If packets before and just after switch is 
>retransmitted the following might occur: Packet A has one rate of the 
>x's and Packet B of the y's.
>
>Original stream   x x A B y y y
>Packet losses         l l
>Retransmission stream  A1 B1 A2 B2 A3
>RTX losses             l  l  l
>
>In the above scenario the retransmission streams switches 5 times very 
>rapidly on the sender side. The receiver although only sees 2 switches. 
>Still, I don't see this as a desired behavior. If one would use a single 
>static RTX pt with its individual RTP TS the retransmission stream would 
>not switch a single time. The reconstructed packets would simply have 
>there correct RTP TS. So having larger or smaller synchronization 
>problems when switching rate depends if the RTP TS is used to transport 
>the original or not.

Okay, but you'd need to restrict the clock for the retransmission stream,
such that the timing of the original streams can be exactly deduced from
the clock in the retransmission.

>Having a RTP TS based on send time is nicer as it doesn't screw up the 
>RTCP measurements and instead allows them to work as intended. If we 
>sometimes in the future are going to do a new version of RTP we really 
>should consider having two timestamps. One for media synchronization and 
>another one for transport statistics.
>
>However I don't know it these nice things is worth the four byte in 
>extra overhead for each retransmitted packet. Especially as they aren't 
>really needed for the retransmitted stream.

The RTCP jitter statistics are probably not useful for the retransmission
stream anyway?

Colin
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt