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

From: [email-masked]
Date: Thu, 31 Mar 2011 09:21:44 -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: Roni Even <[email-masked]>
Date: Thu, 31 Mar 2011 18:49:43 +0200

Hi,
Using SSRC is not the right way. It will be better to have this information
as part of the RTP payload specification of the specific codec and send it
with the payload. Example is parameter sets in H.264

In RFC3984 and RFC3984bis (H.264 payload) even if parameter sets are sent
out of band in SDP they have an ID that is used in the payload or payload
header and not part of the RTP header.

I am not sure why you do it out of band and if it is for a specific codec or
a general mechanism.

Roni Even

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Thursday, March 31, 2011 6:22 PM
> To: [email-masked]
> Subject: [AVTCORE] Synchronization source for synchronizing stream
> changes?
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: [email-masked]
Date: Thu, 31 Mar 2011 19:42:47 -0700

Thanks, I'll check out H.264 parameter sets.

The main reason I planned to do it out-of-band is that I have a
reliable TCP-based RTSP channel and RTP data goes over unreliable UDP.
I use an FEC scheme for RTP video data, but if there is more loss than
FEC can recover from, I just move on. But for this data, it's critical
for it to not be dropped so I would need to re-implement a TCP-like
scheme for loss recovery.

One thing that also complicates this is that the codec can change
dynamically (it adapts to network conditions, type of content, etc.).
I can use the payload type to some extent, but that usually assumes
some level of pre-configuration when the RTP stream is setup (e.g. SDP
rtpmap lines) and there's a pretty limited number of dynamic payload
types (and I have multiple concurrent RTP streams of differing types,
which reduces the payload type range further).

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.

---

From: Roni Even <[email-masked]>
Date: Fri, 01 Apr 2011 08:09:47 +0300

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

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, April 01, 2011 5:43 AM
> To: Roni Even
> Cc: [email-masked]
> Subject: Re: [AVTCORE] Synchronization source for synchronizing stream
> changes?
>