RE: [AVT] draft-ietf-avt-rtp-svc-03.txt and RFC 3984 (sprop-parameter-sets)

["Even, Roni" <roni.even at polycom.co.il>]

Randell,
A FIR is used to get a synchronization point. For H.263 and H.261 it was
full picture. But for H.264 you need the parameter set. The assumption
is that there was for example a video switch so a party connected to the
video in the middle of the stream.
Now the source gets a FIR, what is his behavior, does it sent the
parameter sets in the signaling or in the media path. 

Roni 

> -----Original Message-----
> From: Randell Jesup [mailto:rjesup at wgate.com]
> Sent: Thursday, November 29, 2007 7:24 PM
> To: Even, Roni
> Cc: avt at ietf.org; Jonathan Lennox
> Subject: Re: [AVT] draft-ietf-avt-rtp-svc-03.txt and RFC 3984 (sprop-
> parameter-sets)
> 
> "Even, Roni" <roni.even at polycom.co.il> writes:
> >I understand why most H.264 video conferencing will not use
> >sprop-parameter-sets. I think this was not a good idea. Synchronizing
> >between signaling and media is not there.
> 
> So how then do you guarantee the parameter set is available?  (And
that
> it's the 'right' one)?  In-stream use, though common, mostly works
when
> there's only a single set and they never, ever change.  It also wastes
> bandwidth.
> 
> If you're changing/adding parameter sets in-stream, you're betting on
luck
> that they get through, and probably sending them on every IDR (and
perhaps
> either forcing extra IDRs or extra SPS/PPS's into the stream, in case
they
> got lost).
> 
> Or you have to come up with a separate reliable transport over RTP and
> RTCP, or re-use/mis-use some other SIP command to change them (INFO).
> 
> >Using re-invite for changing sets or as a response for FIR is not the
> >best solution.
> 
> Who would use re-INVITE as a response to FIR?  Either they're
in-stream
> (in
> opposition to the RFC, though harmless if they're the same as the
> sprop-parameter-set value), in which case you can repeat them in
response
> to an FIR, or they were in signalling to start with, in which case you
> don't need to re-INVITE to send them.
> 
> >We moved all media control requests (fast update) to the
> >media path and now you have to send the parameter sets in the
signaling
> >path so what was gained, we lost more since INFO has less overhead on
> >the SIP UA then the re-Invite
> 
> Parameter sets need a reliable transport, unlike fast-update.
Fast-update
> has nothing to do with parameter sets.  And are you saying we should
send
> parameter updates via INFO?  We could do that, and it can be reliable
and
> lower-overhead than re-INVITE, but I've never seen a spec for it, and
also
> how often do you expect to change parameter sets?  It also could
> complicate
> things like B2BUA's, I'd think.
> 
> --
> Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga
OS
> team
> rjesup at 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 at ietf.org
https://www1.ietf.org/mailman/listinfo/avt