LGTM2

On Mon, Mar 10, 2025 at 9:32 AM Philip Jägenstedt <foo...@chromium.org>
wrote:

> LGTM1 with the same caveats as for MediaRecorder
> <https://groups.google.com/a/chromium.org/g/blink-dev/c/YJ1QijNiHeM/m/TvOaEu2sAQAJ>
> :
>
>    - The approval is only for exposing OS-provided HEVC support, not for
>    other OS-provided codecs, and not for browser-provided HEVC.
>    - That there is a well established alternative in AV1 is important.
>    - We're open to mitigations like Finch-disabling support for a
>    percentage of users to ensure that HEVC support cannot be taken for 
> granted.
>
>
> It sounds like making the decision about which codec to use might still be
> challenging in some cases, but that seems like a preexisting issue and as
> Henrik says it's not codec-specific. If there are additional things that
> could be exposed to make this easier that would be great as a separate I2S.
>
> On Mon, Mar 10, 2025 at 4:57 PM Jianlin Qiu <jianlin....@intel.com> wrote:
>
>> > AV1 encode support is missing, decode support is there. Hardware
>> encoders for RTC are extremely tricky (which is the reason OpenH264 is
>> still very much needed)
>>
>> AV1 HW encoding: On Intel it requires Core Ultra series or above, or
>> A-series discrete graphics; On NV it requires RTX 4000+ series; On AMD it
>> you need Zen5+.
>> For HEVC HW encode, Edge does not enable this feature, so you'll not see
>> it in the HW accelerator list in edge://gpu.
>>
>> On Monday, March 10, 2025 at 7:13:08 PM UTC+8 Harald Alvestrand wrote:
>>
>>> Thanks for pushing the profile document! It's a bit late to get it on
>>> the agenda for AVTCORE at IETF 122, but it should be possible to continue
>>> discussing it in email / trackers.
>>>
>>> (for the benefit of listeners: RFC 7798, published in 2016, is the basic
>>> spec for H.265 in RTP.
>>> draft-ietf-avtcore-hevc-rtp is an attempt to profile that rather
>>> expansive format in a way appropriate for use with WebRTC applications.)
>>>
>>> On Sun, Mar 9, 2025 at 9:04 PM 'Philipp Hancke' via blink-dev <
>>> blin...@chromium.org> wrote:
>>>
>>>> I'll still try to get
>>>> https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-hevc-webrtc
>>>> through the IETF but it has been extremly valuable for shaping the
>>>> implementation already.
>>>>
>>>> Speaking as an individual below.
>>>>
>>>> API owners: this sounds like an opportunity to elaborate the Chromium
>>>> position a bit more than the very brief statement cited in
>>>>
>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/YJ1QijNiHeM/m/3EhMjMVwAgAJ
>>>>
>>>> Am Di., 4. März 2025 um 02:34 Uhr schrieb Henrik Boström <
>>>> hb...@chromium.org>:
>>>>
>>>>> AV1 is great from a quality perspective, but it is not an option for
>>>>> use cases that require hardware acceleration. Diego mentioned potential
>>>>> server-side requirements, on the client-side estimates are only 8% Windows
>>>>> endpoints and 0% macOS endpoints have HW accelerated AV1 support. For
>>>>> mobile clients (including native apps which need to be able to interop 
>>>>> with
>>>>> web clients in video conferencing use cases), it's 0% Android/iOS as well.
>>>>> As web apps are becoming more taxing on performance and battery (e.g. 
>>>>> video
>>>>> effects processing becoming default) and increased expectations on video
>>>>> quality, hardware accelerated alternatives is important for both older and
>>>>> newer devices running modern web apps and for interop with mobile clients.
>>>>
>>>> H.265 is a different story: HW support is 75% Windows, 99% macOS, 86%
>>>>> Android, 90% iOS. This goes back to devices from a decade ago which are
>>>>> still common in the wild.
>>>>>
>>>>
>>>> Are those numbers encode, decode or both? The motivator in this space
>>>> is typically streaming movies which has created a lot of asymmetry between
>>>> decoding and encoding.
>>>> Take this from edge://gpu on my Windows machine (Intel and NV 3060 GPU)
>>>> [image: image.png]
>>>> AV1 encode support is missing, decode support is there. Hardware
>>>> encoders for RTC are extremly tricky (which is the reason OpenH264 is still
>>>> very much needed)
>>>>
>>>> From a quality perspective, this is the only codec that is close to
>>>>> AV1.
>>>>>
>>>>
>>>> No. HEVC is generally considered to be the equivalent of VP9 so
>>>> comparing it to AV1 is slightly off.
>>>>
>>>> H.26*4* does *not* fit that bill. Hardware acceleration has been
>>>>> measured to reduce power consumption by 20% in basic calling use cases and
>>>>> above 30% when video effects processing is enabled. Combine this with the
>>>>> fact that video conferencing use cases draws >10X more power than when the
>>>>> laptop not doing heavy work (like lite web browsing) and you can imagine
>>>>> this can have a material impact on your device's overall battery life, not
>>>>> to mention improving the performance, unblocking higher resolutions and
>>>>> more CPU budget for features as well as unblocking HW acceleration in
>>>>> mobile-to-web calling and higher resolution use cases for the future.
>>>>>
>>>> I do not expect the need for AV1 to go away, but I think a compliment
>>>>> is needed for the hardware/quality balance.
>>>>>
>>>>
>>>> Hard to argue with the power consumption win for decoding.
>>>>
>>>> But as my friends from xcloud say an event for when fallback (or due to
>>>> lack of SW fallback: failure and freezes) happens would be essential to
>>>> have.
>>>> I have never seen a follow-up on the "privacy concerns" cited in the
>>>> meeting notes for
>>>>
>>>> https://github.com/w3c/webrtc-extensions/issues/146#issuecomment-1822368254
>>>>
>>>> Philipp
>>>> who prefers to spend his time improving WebRTC/AV1
>>>> <https://issues.webrtc.org/issues/42226301> even on the web
>>>>
>>>>
>>>>> On Monday, March 3, 2025 at 7:36:40 PM UTC+1 Diego Perez Botero wrote:
>>>>>
>>>>>> Alex - AV1 isn't an option for all WebRTC use cases due to hardware
>>>>>> limitations. For instance, for Xbox Cloud Gaming, we do not have AV1
>>>>>> encoding capabilities on our server hardware and would benefit
>>>>>> substantially from having H265 decode support on browser clients. We can
>>>>>> already get that working end-to-end with Safari, so Chromium-based 
>>>>>> browsers
>>>>>> essentially have a feature gap in their WebRTC implementation at this
>>>>>> point. Also note that the H265 support being tracked here is only for 
>>>>>> when
>>>>>> the client has *hardware *support for the codec, so the licensing
>>>>>> implications are mitigated.
>>>>>>
>>>>>> On Monday, March 3, 2025 at 8:15:16 AM UTC-8 Alex Russell wrote:
>>>>>>
>>>>>>> Hey Henrik,
>>>>>>>
>>>>>>> I'd like to understand the case for the API OWNERS approving more
>>>>>>> support for patent encumbered codecs when we have AV1. Apple continues 
>>>>>>> to
>>>>>>> use its hardware to push closed solutions in this space, and I 
>>>>>>> understand
>>>>>>> the instinct, but I'd like to see quantified benefits.
>>>>>>>
>>>>>>> Best,
>>>>>>>
>>>>>>> Alex
>>>>>>>
>>>>>>> On Monday, March 3, 2025 at 2:36:23 AM UTC-8 Henrik Boström wrote:
>>>>>>>
>>>>>> Contact emails
>>>>>>>> hb...@chromium.org, jianlin.q...@intel.com, es...@chromium.org
>>>>>>>>
>>>>>>>> Specification
>>>>>>>> WebRTC: https://w3c.github.io/webrtc-pc
>>>>>>>>
>>>>>>>> But there are no new API surfaces, just a new mime type addition
>>>>>>>> exposed in existing APIs - the new mime type ("video/H265") is 
>>>>>>>> queryable
>>>>>>>> via MediaCapabilities API:
>>>>>>>>
>>>>>>>> https://w3c.github.io/media-capabilities/#dom-videoconfiguration-contenttype
>>>>>>>>
>>>>>>>> If supported it will show up in SDP generated by WebRTC and
>>>>>>>> sender/receiver capabilities which can be used to set codec
>>>>>>>> preferences
>>>>>>>> <https://w3c.github.io/webrtc-pc/#dom-rtcrtptransceiver-setcodecpreferences>
>>>>>>>>  (existing
>>>>>>>> WebRTC API). Note that the codec is only used if successfully 
>>>>>>>> negotiated,
>>>>>>>> meaning if the other endpoint does not support the codec then a 
>>>>>>>> different
>>>>>>>> one is automatically used instead.
>>>>>>>>
>>>>>>>> Summary
>>>>>>>>
>>>>>>>> This newer codec has increased compression efficiency (higher
>>>>>>>> quality per bitrate) relative to VP8/VP9/H264 and very strong hardware
>>>>>>>> support going back over a decade. This translates into improved visual
>>>>>>>> experience, increased battery life and reduced risk of performance 
>>>>>>>> issues.
>>>>>>>> The codec is already industry standard and we should support it in 
>>>>>>>> WebRTC
>>>>>>>> when provided by the platform, i.e. if it is available in hardware. 
>>>>>>>> This
>>>>>>>> codec is already available in WebCodecs (M130) and MediaRecorder APIs (
>>>>>>>> soon?
>>>>>>>> <https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/YJ1QijNiHeM>).
>>>>>>>> Support will be queryable via MediaCapabilities API. Safari has already
>>>>>>>> shipped support in WebRTC.
>>>>>>>>
>>>>>>>> H265 encoding is only available if the user's device and operating
>>>>>>>> system provide the necessary capabilities as we will not provide a 
>>>>>>>> software
>>>>>>>> implementation to fall back to.
>>>>>>>>
>>>>>>>> Blink component
>>>>>>>> Blink>WebRTC>Video
>>>>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EWebRTC%3EVideo%22>
>>>>>>>>
>>>>>>>> TAG review/status
>>>>>>>> N/A, small incremental change
>>>>>>>>
>>>>>>>> Risks
>>>>>>>> Interoperability and Compatibility
>>>>>>>>
>>>>>>>> No significant backwards compat risk since the codec is only used
>>>>>>>> if both endpoints negotiate it. Interop risk is also very small for the
>>>>>>>> same reason - note that while this codec is new, needing to
>>>>>>>> negotiate support else falling back to a different format is not a new
>>>>>>>> dynamic: old codecs like H264 (that's ...4, not ...5) for example come 
>>>>>>>> in
>>>>>>>> different flavors (profile IDs) where support is also HW and 
>>>>>>>> implementation
>>>>>>>> specific and need to be negotiated, to that regard this is not
>>>>>>>> fundamentally any different.
>>>>>>>>
>>>>>>>> *Gecko*: Standards position link:
>>>>>>>> https://github.com/mozilla/standards-positions/issues/1188
>>>>>>>> (Firefox has some non-WebRTC support for H265 already such as media
>>>>>>>> playback <https://bugzilla.mozilla.org/show_bug.cgi?id=1924066>).
>>>>>>>>
>>>>>>>> *WebKit*: Shipped, including WebRTC support.
>>>>>>>>
>>>>>>>> *Web developers*: Strongly positive. This includes both internal
>>>>>>>> and external developers who have both contributed code and emails 
>>>>>>>> asking
>>>>>>>> for timelines.
>>>>>>>>
>>>>>>>> WebView application risks
>>>>>>>>
>>>>>>>> None
>>>>>>>>
>>>>>>>> Debuggability
>>>>>>>>
>>>>>>>> N/A
>>>>>>>>
>>>>>>>> Will this feature be supported on all six Blink platforms (Windows,
>>>>>>>> Mac, Linux, ChromeOS, Android, and Android WebView)?
>>>>>>>> Yes
>>>>>>>>
>>>>>>>> Is this feature fully tested by web-platform-tests
>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>>>>>>> ?
>>>>>>>> Yes
>>>>>>>>
>>>>>>>> Flag name on about://flags
>>>>>>>> No new flags are added specific to this codec but there are
>>>>>>>> existing flags to disable  HW acceleration (any codec) which would also
>>>>>>>> disable H265.
>>>>>>>>
>>>>>>>> Finch feature name
>>>>>>>> WebRtcAllowH265Send for H265 encoding support and
>>>>>>>> WebRtcAllowH265Receive for H265 decoding support
>>>>>>>>
>>>>>>>> Requires code in //chrome?
>>>>>>>> False
>>>>>>>>
>>>>>>>> Tracking bug
>>>>>>>> https://crbug.com/391903235
>>>>>>>>
>>>>>>>> Estimated milestones
>>>>>>>> Shipping on desktop
>>>>>>>> 136
>>>>>>>> Shipping on Android
>>>>>>>> 136
>>>>>>>> Shipping on WebView
>>>>>>>> 136
>>>>>>>>
>>>>>>>> Anticipated spec changes
>>>>>>>>
>>>>>>>> None
>>>>>>>>
>>>>>>>> Link to entry on the Chrome Platform Status
>>>>>>>>
>>>>>>>> https://chromestatus.com/feature/5153479456456704?gate=5188857236291584
>>>>>>>>
>>>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "blink-dev" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to blink-dev+...@chromium.org.
>>>>> To view this discussion visit
>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ecdcb150-2719-4040-99d3-3a18fbcbe230n%40chromium.org
>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ecdcb150-2719-4040-99d3-3a18fbcbe230n%40chromium.org?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "blink-dev" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to blink-dev+...@chromium.org.
>>>>
>>> To view this discussion visit
>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKi%2BecT1SQuQVdMX6nTANCsHw6xnCrTWwTxZOkY3onkPafw%40mail.gmail.com
>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKi%2BecT1SQuQVdMX6nTANCsHw6xnCrTWwTxZOkY3onkPafw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/16ccc499-3a25-4a85-a9c5-c56f0d6f489an%40chromium.org
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/16ccc499-3a25-4a85-a9c5-c56f0d6f489an%40chromium.org?utm_medium=email&utm_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYfHZTE4GLr6YP7_o56KJGXP_r8KiYtqv9w1HOiHvXF0vg%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYfHZTE4GLr6YP7_o56KJGXP_r8KiYtqv9w1HOiHvXF0vg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-tQD56zsGuW1fUWTyhc%3DC141%3DqFBeJdCwid64XabdXLA%40mail.gmail.com.

Reply via email to