Re: "Automatic" use of scalable video coding?

I agree, if the receiver side doesn't need some configuration (like VP8
temporal layers) it should be ok not to set it.    Maybe at some point we
need a "document" to explain what are those options depending on the
codec/browser.

Regarding maxTemporalLayers agree that we need to know how to specify "no
limit".   I don't know how is it done in other W3C APIs (not set vs
MAX_INT).

Do you envision any use case where it is valuable for the browser to enable
SVC without the developer explicitly asking for it?  Unless there is a
relevant use case I would say SVC should be only activated if the developer
ask for it or it is the only mode of a specific codec.




On Fri, Sep 12, 2014 at 10:15 PM, Peter Thatcher <pthatcher@google.com>
wrote:

> On the receive side, if certain parameters don't need to be known,
> then I would say that they don't need to be set.  Hopefully someday
> the header extensions will have enough information that nothing will
> be needed other than some IDs.
>
> But I don't think the sender should send more than one layer unless
> the parameters say to.  Anything to simplify things for convenience
> purposes can be done via a library, so it doesn't seem that important
> to make it too automatic for the sender.
>
> On Wed, Sep 10, 2014 at 3:00 PM, Bernard Aboba
> <Bernard.Aboba@microsoft.com> wrote:
> > Currently within the ORTC API specification, Section 9.9 provides
> examples
> > of how to set up encoding parameters to support simulcast and/or scalable
> > video coding (SVC).
> >
> >
> >
> > While some developers might be interested in controlling exactly how
> > simulcast and SVC are used in their applications, other developers would
> > probably be happier if they could leave that to the browser.   Looking at
> > the current specification, it appears to me that SVC configuration
> within an
> > RTCRtpReceiver might be unnecessary for some video codecs, and in
> addition,
> > it might be possible to dispense with configuring the SVC configuration
> > within an RTCRtpSender in some cases as well.
> >
> >
> >
> > Below is my understanding of how “automatic” use of SVC works on the
> > RTCRtpReceiver and how it might work on an RTCRtpSender.
> > Comments/corrections/suggestions welcome.
> >
> >
> >
> > In situations where a compliant decoder can decode any valid encoding, it
> > would appear to me that it is not necessary to set up the SVC
> configuration
> > within RTCRtpReceiver.receiver.  Essentially, the decision whether to
> > utilize scalable video coding can be left to the sender.   If the
> receiver
> > can handle anything that the sender can send, there isn’t even a need for
> > negotiation, such as an exchange of capabilities.
> >
> >
> >
> > To give a practical example, if a VP8 decoder can decode any valid VP8
> > encoding, including temporal scalability, it seems to me that an
> > RTCRtpReceiver would not need to configure an SVC layer configuration
> within
> > RTCRtpEncodingParameters.  In the event that a layering configuration is
> > provided (e.g. two temporal layers are expected) the RTCRtpSender should
> > still be free to send something else (e.g. maybe only 1 temporal layer,
> or
> > perhaps 3) without a resulting error.   So it seems to me that for the
> > RTCRtpReceiver, configuration of SVC layering is somewhat extraneous.
> Also,
> > I’m not clear about the usefulness of having
> RTCRtpReceiver.getCapabilities
> > return a value for RTCRtpCodecCapability.maxTemporalLayers.   Where
> > maxTemporalLayers is not set, the default interpretation could be “I can
> > handle the maximum temporal layers supported by the codec.”
> >
> >
> >
> > For an RTCRtpSender, it does seem useful for the developer to be able to
> > indicate whether to use temporal scalability or not.  For example, in
> > peer-to-peer communication the overhead of SVC might not make sense, so
> it
> > might be useful to be able to specify only a single layer in
> > RTCRtpSender.send().   On the other hand, there might be situations where
> > the developer would just as soon leave the decision to use SVC up to the
> > browser.   Rather than trying to adjust the number of temporal layers
> within
> > the application, the browser could decide how many layers might make
> sense.
> >
> >
> >
> > Currently within RTCRtpEncodingParameters, it doesn’t appear that a
> > developer can indicate to the browser “Send SVC if you think it is
> useful”.
> > For example, within the RTCRtpEncodingParameters dictionary there is no
> > “maxTemporalLayers” attribute.   All you have is encodingId and a
> sequence
> > of dependencyEncodingIds.
> >
> >
> >
> >
> >
> >
> >
> > dictionary RTCRtpEncodingParameters {
> >
> >     unsigned long       ssrc;
> >
> >     payloadtype         codecPayloadType;
> >
> >     RTCRtpFecParameters fec;
> >
> >     RTCRtpRtxParameters rtx;
> >
> >     double              priority = 1.0;
> >
> >     double              maxBitrate;
> >
> >     double              minQuality = 0;
> >
> >     double              framerateBias = 0.5;
> >
> >     double              resolutionScale;
> >
> >     double              framerateScale;
> >
> >     boolean             active = true;
> >
> >     DOMString           encodingId;
> >
> >     sequence<DOMString> dependencyEncodingIds;
> >
> > };
> >
> >
> >
> >
>
>