Re: Signalling of start / stop

Harald Alvestrand said:


"WRT stop(), I put this in -msid:

   o  When a description is updated to no longer list the msid value on
      any m-line, the recipient can signal to its application that the
      media stream has been closed.

   In addition to signaling that the track is closed when it disappears
   from the SDP, the track will also be signaled as being closed when
   all associated SSRCs have disappeared by the rules of [RFC3550]
   section 6.3.4 (BYE packet received) and 6.3.5 (timeout).

This was the result of some discussion. I think it would be nice to
consistently apply this."

[BA] The text above applies to individual video streams as well as for "application layer" simulcast where each stream is an individual MediaStreamTrack.   However, there are some additional wrinkles that need to be taken into account for "native" simulcast or scalable video coding, where it may be desirable to stop, pause or resume an individual stream or layer which might be represented as a "Channel" rather than an individual MediaStreamTrack.

Adalberto Forest said:


"Add a state {enabled, disabled or active, inactive} attribute to RTCRtpSender and RTCRtpReceiver."



[BA] If the desire is to provide information on the state of an individual stream within a simulcast or layered coding within the "native" model that Peter suggested, then it may be necessary to add a state for each of the streams, not just a single state for the entire RTCRtpSender and RTCRtpReceiver objects.


For example, in "native" simulcast it might be desirable to tell the sender to stop sending one of the streams that is being simulcast, rather than all of them.  This would result in a BYE packet being sent for the specific SSRC/stream(s) that are being stopped.  Similarly, if a single simulcast stream is being paused, it may make sense to send a TMMBR message with a zero in the maximum total media bitrate for that specific SSRC/stream.   To represent the state of the individual streams, you would then need corresponding states.

Note that when scalable video coding is involved, individual "Channels" may not necessarily be uniquely identified by SSRC.   While in Multi-Stream Transport (MST) of Scalable Video Coding, individual layers can utilize their own SSRCs, in Single Stream Transport (SST) (as utilized by most implementations of H.264/SVC as well as by VP8), all layers within a single RTP session utilize the same SSRC.   Therefore a BYE packet sent to an SST sender would imply that the sender will stop sending all layers associated with the SSRC/CSRC in the packet, and a TMMBR message sent by the receiver with zero in the maximum total media bitrate would result in the sender pausing all layers associated with the SSRC in the packet.

In SST, the way to act on individual layers may depend on the codec involved.   For example, if the desire is for a VP8 sender to stop sending a layer, then the RTCRtpSender encoding parameters could be changed to revise the encoding.  Since in VP8 the decoder is required to be able to decode anything that the encoder can send, it doesn't appear to me that the encoder is required to tell the decoder that the change is coming, via signaling or any other mechanism.   On the other hand, in H.264/SVC the SEI message is typically sent to indicate dropping of a layer, even if there is no signaling to that effect.

This suggests to me that if we are going to use a single RTCRTPSender object to handle "native" simulcast or layered coding then we may need provide controls on individual Channels rather than calling stop(), pause() or resume() on RTCRTPSender objects.