LGTM3 On Monday, March 10, 2025 at 7:33:15 PM UTC+1 Chris Harrelson wrote:
> 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/b8db61fb-d589-4a3b-9e48-12b6d578966dn%40chromium.org.
