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

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

Hi Bernard,

Thank you very much for your feedback, comments below inline.

On Fri, Feb 24, 2023 at 10:56 PM Bernard Aboba <[e-mail]>
wrote:

> Here is my (belated) review.
>
> Section 1
>
> “ While WebRTC has been very successful in a wide range of scenarios,
>
>    its adoption in the broadcasting/streaming industry is lagging
>
>    behind.”
>
> [BA] I recently saw a survey indicating that WHIP is now the second most
> implemented ingestion protocol, second only to RTMP.  So while this
> sentence may have been correct at one time, it seems out of date now.  Can
> we delete this sentence?
>
> Also, overall Section 1 seems like it could be shortened considerably by
> highlighting the major points. Here is my suggestion:
>
>
I am ok with changing the introduction, will review your text and propose a
PR with your changes.


> Section 2
>
>
> I do not see a definition of “track”.  I think this is important to clarify.
>
>
 I already had a PR related to that adding a reference to RFC8830.

https://github.com/wish-wg/webrtc-http-ingest-protocol/pull/95

Do you think it would be enough?



> Section 4.2
>
> “  While this version of the specification only supports a single audio
>
>    and video track, in order to ensure forward compatibility, if the
>    number of audio and or video tracks or number streams is not
>    supported by the WHIP Endpoint, it MUST reject the HTTP POST request
>    with a "406 Not Acceptable" error response.”
>
>
> [BA] Support for stereo and surround-sound is becoming increasingly popular.  Can you clarify whether this is supported in this version of the specification?  I assume it can be (e.g. it is possible to have multiple channels per track) but the lack of a definition for “track” creates some uncertainty.
>
>
>
Yes, this is definitely possible, see me comment about using track as
defined in RFC8830. Given that stereo and surround sound are SDP
negotiated, do you think that we need to include any further clarification
apart of the track one?


> 4.6.  Simulcast and scalable video coding
>
>    Both Simulcast [RFC8853] and Scalable Video Coding (SVC), including
>    K-SVC (also known as "S modes", in which multiple encodings are sent
>    on the same SSRC), MAY be supported by both the Media Servers and
>    WHIP clients through negotiation in the SDP offer/answer.
>
> [BA] K-SVC and “S” modes are different.  K-SVC denotes the KEY and KEY_SHIFT modes, whereas “S” modes denote the encapsulation of multiple encodings within a single SSRC, as is supported in VP9 and AV1.   Diagrams of the various modes are included in the WebRTC-SVC specification: https://w3c.github.io/webrtc-svc/
>
>
> Also, SVC is *not* negotiated within Offer/Answer in WebRTC.  It is something that the encoder can just turn on.  At least for temporal modes (L1T2, L1T3) ingester support can often be taken for granted.  While the VP9 and AV1 specifications require a compliant decoder to be able to decode any mode than an encoder can encode, in practice there are VP9 and AV1 hardware decoders that cannot decode spatial scalability because they do not support spatial references (e.g. a P-frame at a higher resolution than the P or I frame that it references).
>
>
> This nasty little “wrinkle” required us to define the “spatialScalability” attribute in Media Capabilities, to allow applications to discover whether a (hardware) decoder supports spatial scalability or not:
>
> Media Capabilities <https://www.w3.org/TR/media-capabilities/#dom-videoconfiguration-spatialscalability>
> w3.org <https://www.w3.org/TR/media-capabilities/#dom-videoconfiguration-spatialscalability>
> [image: favicon.ico] <https://www.w3.org/TR/media-capabilities/#dom-videoconfiguration-spatialscalability> <https://www.w3.org/TR/media-capabilities/#dom-videoconfiguration-spatialscalability>
>
> Not sure if you want to get into this in the specification.  Issues are most likely to be encountered where hardware-based transcoders are used (but in that scenario, spatial scalability probably wouldn’t be relevant anyway),
>
>
>
 I agree with you, should we remove the reference to SVC completely and
only leave simulcast support in that section?

Best regards
Sergio