Hardware acceleration and fingerprinting
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 30/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- javascript
- Área
- api, audio-video-rtc
Línea de trabajo
Comienza por la sección sobre aceleración por hardware de la especificación de WebCodecs y el ejemplo de VideoEncoder.isConfigSupported; después, revisa el informe de Bugzilla enlazado y los dos comentarios existentes. La issue estará terminada cuando se hayan acordado y especificado el comportamiento de hardwareAcceleration bajo restricciones de fingerprinting y el resultado observable para los autores.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
I just filed a bug on Bugzilla but what Firefox is doing is spec compliant, so I wanted to raise the issue here too.
Background
I'm making a website that heavily utilizes WebCodecs. I need to determine the encoding codec and always want to use hardware encoding (when available) as battery life is more important than fidelity (conference call).
- Loop through all codecs in order of network efficiency: av1, vp9, hevc, h254, vp8, etc
- Check if the browser supports hardware acceleration, if so return it.
- Repeat the loop but this time with software acceleration.
I'm using the hardwareAcceleration: "prefer-hardware" field to determine if hardware acceleration is supported. Here's an example of one of the checks:
VideoEncoder.isConfigSupported({
codec: "av01.0.08M.08",
width: 1280,
height: 720,
hardwareAcceleration: "prefer-hardware",
}).then(console.log)
Here's a little modal I created to visualize the process and the results on my M2 laptop and Chrome.
Problem
Here's what Firefox reports:
Ignore the partial support for video capture (MediaStreamTrackProcessor polyfill).
The problem is that Firefox is reporting hardware acceleration for AV1, VP9, etc. So my encoder will naively select one of those codecs and suddenly my CPU is on fire.
My guess is that Firefox is ignoring the hardwareAcceleration field to avoid fingerprinting. Here's the relevant section in the specification:
If a User Agent does not implement [media-capabilities] for reasons of fingerprinting, they SHOULD ignore the HardwareAcceleration preference
Proposed
If the browser won't respect hardwareAcceleration because it can be used for fingerprinting, then the browser should return an error somehow. I don't think the browser should silently ignore important configuration values without feedback.
If I knew that Firefox doesn't allow probing for hardware acceleration, then I would use H.264 because hardware acceleration is very common and easier on the CPU. Then I could also report hardware acceleration as "unknown" and maybe show a modal explaining why performance might be poor.
My suggestions:
- Don't return
hardwareAccelerationin the config returned by isConfigSupported. Unfortunately, this isn't quite correct, ashardwareAccelerationis supported but only as a hint. - Add
"require-hardware"and"require-software"as options, throwing an exception (or returning false?) if they are used on browsers that care about fingerprinting. - Firefox pls allow me to detect hardware acceleration. Otherwise I can't use newer codecs for fear of melting silicon.
I think #2 is the best option. It's kind of strange that Chrome returns isConfigSupported=false when "prefer-hardware" is used. If it's just a hint, like the "prefer" implies, then it should always return true if either software or hardware encoding is available... right?
- Lenguaje dominante
- HTML
- Estrellas
- 1.3k
- Forks
- 192
- Merge medio
- 3 h 36 min
- PR fusionados (30 d)
- 7
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de w3c/webcodecs
-
privacy-needs-resolution
Dificultad 1/5 Menos de una hora Aptitud para principiantes 65/100
Los mantenedores suelen responder en 1 día
-
editorial
Dificultad 1/5 Menos de una hora Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
Los mantenedores suelen responder en 1 día
-
TPAC2026
Dificultad 5/5 Más de una semana Aptitud para principiantes 8/100
Los mantenedores suelen responder en 1 día
Todos los issues de w3c/webcodecs
Issues similares
-
Remove song from playlistAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
maxrave-dev/SimpMusic#2649 ·
Los mantenedores suelen responder en 2 días
-
product/backlog
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
TencentBlueKing/bk-nodemgr#3645 ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 2 días
-
Objects.List treats versions=false (and similar flags) as truePosiblemente ocupada @andaaron la tomó hoy. Abiertopriority: p2 type: bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
googleapis/storage-testbench#829 ·
Los mantenedores suelen responder en 2 días
-
[Bug]: memory provider treats 1:1 DMs as shared surfaces, so DM turns never receive reviewed recordsAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 79/100
rlaope/oh-my-hermes#2088 ·
Los mantenedores suelen responder en 1 día