Contact emails
[email protected], [email protected], [email protected]
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 [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/dc0e11bc-5ca2-47f8-b01b-0deedb3a1038n%40chromium.org.
