Is your feature request related to a problem? Please describe.
By default, CEF/Chromium builds have proprietary codecs (H.264/AAC) disabled [1]. This is due to patent portfolio licensing requirements when using the FFmpeg library for software decoding of proprietary codecs (via the ffmpeg_branding=Chrome part). If you enable and distribute (via FFmpeg configuration) a software implementation of the patent protected technology as part of your application then you will likely be subject to said licensing requirements and associated costs.
[1] Proprietary codecs are marked as "Google Chrome only" at https://www.chromium.org/audio-video/ and can generally be enabled by building CEF/Chromium with the proprietary_codecs=true ffmpeg_branding=Chrome GN arguments.
Describe the solution you'd like
On Windows and MacOS, a (preferred) hardware video decoding path using OS platform APIs already exists in Chromium, and this implementation does not depend on configuring or distributing FFmpeg with software decoding of proprietary codecs enabled (leave out the ffmpeg_branding=Chrome part [2]). The OS manufacturers (Microsoft and Apple respectively) allow applications to use these OS platform APIs with no added licensing requirements or costs. We can consequently enable hardware-only support for proprietary video codecs (via OS platform APIs) with only minor changes to the existing CEF/Chromium build configuration.
[2] A small patch to disable the assert in media/BUILD.gn is also required.
Additional context
The problem with this approach is that devices lacking hardware decoding support will not be able to play proprietary codecs (due to the lack of software decoding support via FFmpeg). This is most likely to impact Windows users with old or blocklisted GPU hardware. This hardware-only configuration may still make sense for software developers/distributors who are minimally impacted by this population of older Windows hardware or who are otherwise willing to accept this licensing vs functionality trade-off.
8/28/23 SUMMARY OF TEST RESULTS (M117)
- Chromium supports hardware h264 video decoding via OS APIs with minimal changes on Win/Mac.
- Chromium does not (directly) support AAC audio decoding.
- FFmpeg on Mac should theoretically support AAC decoding via AudioToolbox, but we were unable to get it working.
- FFmpeg on Windows does not support decoding via Media Foundation (only encoding).
- Chromium with
proprietary_codecs=true includes additional (non-FFmpeg) proprietary code in //media that may potentially need to be replaced by OS APIs.
See related discussion below.
Is your feature request related to a problem? Please describe.
By default, CEF/Chromium builds have proprietary codecs (H.264/AAC) disabled [1]. This is due to patent portfolio licensing requirements when using the FFmpeg library for software decoding of proprietary codecs (via the
ffmpeg_branding=Chromepart). If you enable and distribute (via FFmpeg configuration) a software implementation of the patent protected technology as part of your application then you will likely be subject to said licensing requirements and associated costs.[1] Proprietary codecs are marked as "Google Chrome only" at https://www.chromium.org/audio-video/ and can generally be enabled by building CEF/Chromium with the
proprietary_codecs=true ffmpeg_branding=ChromeGN arguments.Describe the solution you'd like
On Windows and MacOS, a (preferred) hardware video decoding path using OS platform APIs already exists in Chromium, and this implementation does not depend on configuring or distributing FFmpeg with software decoding of proprietary codecs enabled (leave out the
ffmpeg_branding=Chromepart [2]). The OS manufacturers (Microsoft and Apple respectively) allow applications to use these OS platform APIs with no added licensing requirements or costs. We can consequently enable hardware-only support for proprietary video codecs (via OS platform APIs) with only minor changes to the existing CEF/Chromium build configuration.[2] A small patch to disable the assert in media/BUILD.gn is also required.
Additional context
The problem with this approach is that devices lacking hardware decoding support will not be able to play proprietary codecs (due to the lack of software decoding support via FFmpeg). This is most likely to impact Windows users with old or blocklisted GPU hardware. This hardware-only configuration may still make sense for software developers/distributors who are minimally impacted by this population of older Windows hardware or who are otherwise willing to accept this licensing vs functionality trade-off.
8/28/23 SUMMARY OF TEST RESULTS (M117)
proprietary_codecs=trueincludes additional (non-FFmpeg) proprietary code in //media that may potentially need to be replaced by OS APIs.See related discussion below.