- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Wed, 22 Jan 2014 15:41:33 +0000
- To: Bernard Aboba <Bernard.Aboba@microsoft.com>, Peter Thatcher <pthatcher@google.com>
- CC: "public-orca@w3c.org" <public-orca@w3c.org>, "Harald Alvestrand (hta@google.com)" <hta@google.com>, "Adalberto Foresti (MS OPEN TECH)" <aforesti@microsoft.com>
On 21/01/14 19:51, Bernard Aboba wrote: > Stefan said: > >> I think it is a bad idea to not signal and just stop sending RTP - the >> receiver would then have to guess if the sender stopped sending temporarily, >> or if there are a lot of packet losses, or if there is a speech pause (and >> CN should be generated) etc. > > [BA] I would agree that a packet may need to be sent as the result of a stop(), pause() or resume(). > However, it looks to me like the action may depend on the specific configuration and codec. > > An example of this is SST SVC where in some codecs (e.g. VP8) there may be no packet sent to > indicate dropping a layer, just a reconfiguration of the encoder, whereas in others (e.g. H.264) > a codec-specific packet might be sent (SEI layer drop). > > In MST SVC it is possible that the situation could be different if we can assume thatl WebRTC implementations > understand TMMBR and therefore a TMMBR message with maximum bandwidth of zero might be > used to pause individual layers (or simulcast streams, for that matter). Assuming you mean TMMBN in this case (i.e. the sender pauses) I agree. Section 5.2 in https://datatracker.ietf.org/doc/draft-westerlund-avtext-rtp-stream-pause/?include_text=1 talks about this.
Received on Wednesday, 22 January 2014 15:42:02 UTC