Subject: [MMUSIC] Synchronization source for synchronizing stream changes?

From: [email-masked]
Date: Wed, 30 Mar 2011 11:29:04 -0700

Is it acceptable, from an RTP protocol perspective, to use the
synchronization source ID in the RTP header to synchronize changes in
the RTP stream, such as encoding, display characteristics (e.g.
rotation, scaling), etc.? Or are there better ways to handle this?

When I'm sending video frames via RTP, changes that happen on the
source, such as the encoder config, transforms for display, etc. may
change on a frame-by-frame basis, such as when the user rotates a
source camera or the quality is reduced based on network conditions.
Normally, this is sent via static SDP during session setup, but here
it changes in the middle of a session. When it happens, I send the new
data via a separate channel (e.g. RTCP/RTSP), but this also means it's
possible for RTP video frames to arrive before the updated
configuration info arrives. I need to know to defer trying to decode
or display the frame until the new configuration comes in via the
other channel.

It seemed reasonable to use the synchronization source ID in the RTP
header to indicate this. Whenever something changes, the ssrc could be
incremented so the receiver knows it needs to wait until out-of-band
information about the new ssrc arrives before it processes the RTP
packet. Packets may also be lost so I didn't want to rely on a
one-time thing like the marker bit. Payload type has a pretty small
usable range and I can see it wrapping too quickly for this usage.

Does this break any rules of RTP? Or is there a recommended way to
handle these situations?

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 31 Mar 2011 11:38:37 +0200

This is probably more of an AVT list question, so you may want to 
redirect your question there.

In any case, from an RTP point of view, there is in theory nothing that 
prevents you from changing SSRC at any point during a session, however 
do note that mechanisms have appeared that signal SSRC values as part of 
the application signaling and hence there may be some interaction issues 
to consider there. Similarly, you are describing behavior that is not 
normally associated with an SSRC change, so you would want to make sure 
that your application protocol negotiates support for such semantics.

Thanks

-- Flemming

On 3/30/11 8:29 PM, [email-masked] wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 31 Mar 2011 15:31:04 +0530

To add to Flemming, here are other reasons that can cause SSRC changes
that the application needs to eliminate if it wants to associate a
change in SSRC with a particular cause:
http://www.ietf.org/mail-archive/web/avt/current/msg13669.html

Muthu
 
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Flemming Andreasen (fandreas)
Sent: Thursday, March 31, 2011 3:09 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [MMUSIC] Synchronization source for synchronizing
streamchanges?

Thanks 

-- Flemming