Re: [AVT] Fwd: Retransmission and fast channel change with usage of RTP/RTCP

Colin Perkins <csp@csperkins.org> writes:
>The AVT working group has received the following liaison statement  from
>TISPAN WG3 IPTV on Retransmission and fast channel change with  usage of
>RTP/RTCP. The TISPAN working group asks for our feedback on  a number of
>issues. Please send any comments on this to the chairs by  25 February, so
>we can draft a response.

>> Please find enclosed a liaison statement from TISPAN WG3 IPTV on
>> Retransmission and fast channel change with usage of RTP/RTCP.

Fast channel change: Since they're talking a change into a multicast group,
the limiting factors on a channel change are:

a) Signaling (may overlap)
b) Time to get added to the multicast group
c) Jitter buffer startup time
d) Delay until a iframe/equivalent
(perhaps some others)

An idea floated in that document was joining a unicast stream first, then
switching over to multicast.

For arguments sake, lets assume that in the multicast group iframes are 2
seconds apart, and we don't want channel-change to be <overhead> plus 0-2
seconds.

The proposal would be on channel change, the receiver might both register
to acquire the multicast group AND start receiving a parallel unicast
group.  (Assuming the sender is smart, and this is multicast, NOT
broadcast, then the sender could unicast the temporary stream and add them
to the multicast group at or just before the next multicast iframe.

In RTP terms, the receiver would probably see a source (SSRC) change, from
the unicast source to the multicast source.  If the receiver is
anticipating this it could make the switch fairly smoothly, since barring
loss the new source would start with an iframe.  Loss would need to be
dealt with in the normal way, but in this case the decoder wouldn't have a
"good" buffer to try to handle P/B frames if the first iframe was
lost/corrupted.  It could cheat and use the last frame from the unicast
source, or you could do something like continue to send the unicast source
for one (or more) iframe periods past the expected transition to multicast
- depends on how much bandwidth/encoder-complexity you're willing to allot.

Alternatively I wonder if you could unicast an iframe for the multicast
stream (using the same SSRC/etc), such that the receiver could jump into
the multicast stream before the next "normal" iframe there.  The trick is
that the iframe has to produce a full decoder reference buffer for the
multicast P/B frame stream (or at least one good enough to look ok until
the next real iframe).  It also has to deal with how you'd merge the
unicast and multicast data and deal with sequence/TS/etc issues.  I have a
few hackish ideas, which could work if you relax/break some rules
(duplicate seq/timestamps from the multicast data in the unicast (and send
the unicast iframe 'first' so the multicast data for those sequence numbers
would get ignored as dups, or send a "special" unicast stream with iframe
and a marker telling the decoder where (seq/TS) to switch to decoding the
multicast stream).

Just some late-night ramblings.

-- 
Randell Jesup
rjesup@wgate.com
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
http://www.ietf.org/mailman/listinfo/avt