Subject: Re: [AVTCORE] Synchronization source for synchronizing stream changes?

From: Randell Jesup <[email-masked]>
Date: Tue, 12 Apr 2011 10:54:53 -0400

>> From: [email-masked] [mailto:[email-masked]]

>> A separate ID in the payload can work. I was just thinking to reuse
>> the SSRC since I'm not using it for anything else (and it seemed like
>> this could be viewed as another synchronizing source becoming active).
>> Using an ID in the payload also means I won't be able to use standard
>> payload formats, unless they already have a ID in their specification.

>Hi,
>If it is a specific payload then the information can be in the payload headers or in some payload specific structure.
>For general case look at rtp header extensions in rfc3550 and rfc5285
>Roni

I agree with Roni: for your use-case, given using standard codecs and
packetizations (H.263/264/etc), providing additional information that
needs to be synchronized with the data stream on a frame-by-frame basis
is best done through a header extension (if you want any level of
compliance with the standards).  This has the advantage that if
you try to decode this with something that doesn't know your scheme it
should just work.  It's also more easily extendable than changing an
SSRC (which normally has multiple other possible sources).

If the bandwidth is an issue (hdr ext's don't use much) you could use
some type of handshake over RTCP APP messages (or other back-channel) to
indicate that notification of the 'new' state (rotation, etc) has been
received and the sender can stop adding them.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone)
[email-masked]