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.
