--> 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.
Yes, the RTX packet RTP TS MUST be the same as the one in the original
packet.