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.