Re: [Wish] WG Last Call for draft-ietf-wish-whip

[Sergio Garcia Murillo <[e-mail]>]

On Wed, Mar 8, 2023 at 4:47 PM Bernard Aboba <[e-mail]>
wrote:

>
> On PR 98:
>
> WebRTC conferencing servers commonly send an Offer to receive simulcast,
> which includes the maximum number of streams that the server can support.
> In WHIP, it does not seem like the ingester can send an Offer to receive to
> the encoder. So I guess that the encoder has to look at the Answer to
> understand the ingester limitations (e.g. encoder asked to send 3 streams,
> ingester answered with 2)?
>

Yes, but that is already specified in rfc8853, right? We do not really need
to add anything else to the whip spec.


> With respect to SVC, the issue is really what the decoder can handle. For
> example, software decoders for VP8, VP9 and AV1 can typically decode any
> legal encoding, and H.264/AVC software decoders can commonly handle
> temporal scalability.
>
> Hardware decoders and transcoders are a different story; they can lack of
> support for reference scaling, which prevents decoding spatial scalability
> (or even changing resolution without a key frame).
>
> So I might say “decoder specific” rather than “codec specific”.
>
>
I think that codec-by-codec is still fine, as there are some codecs/modes
that are "safer" to use than others, but I can add a note about the decoder
support:

Scalable Video Coding (SVC) MAY also be supported both by the Media Servers
and WHIP clients. However, there is no universal negotiation mechanism in
(SDP) for SVC, as a result, SVC support must be addressed on a
codec-by-codec basis and taking into account the intended usage and SVC
decoder support.

What do you think?

Best regards
Sergio