> 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.
