Subject: [avtext] RTP switch behavior in draft-berger-avtext-framemarking-00

From: Thomas Daede <[email-masked]>
Date: Fri, 27 Mar 2015 14:46:05 -0700

Currently, the framemarking draft specifies a set of flags and what kind
of concept they map to in various video codecs. However, switch behavior
is only defined based on the I and D bits. How are the other bits, such
as TID intended to be used? Does the switch include RTCP based
throttling logic? Or is there some other sideband that tells the switch
what temporal layer to send?

The TID also seems quite underspecified. To use it smartly, you need to
know the actual number of layers and when it is safe to switch, which is
information only the endpoints would have.

Other nit: instead of defining the I bit as:

MUST be 1 for frames that can be decoded indepedent of prior frames

I would use the text (could use better wording):

MUST be 1 for frames where both the current frame and all future frames
can be decoded without any frames before the frame with the 'I' bit set.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 27 Mar 2015 19:09:25 -0500

On Mar 27, 2015, at 4:46 PM, Thomas Daede <[email-masked]> wrote:
> as TID intended to be used?

[BA] same as it would if it were in the payload.

> Does the switch include RTCP based

[BA] RTCP and signaling are the control channel. Switch decides based on many of the same factors used in congestion control. 

> information only the endpoints would have.

[BA] Max TID could be signaled in which case SFU will have it.  Switching should be informed by TID, S, E bits. 

> _______________________________________________
> avtext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avtext