Align Streaming Protocol Capabilities with Media Capabilities?
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- html
- Área
- api
Línea de trabajo
Start by comparing the Open Screen Protocol streaming capability fields with the Media Capabilities API’s AudioConfiguration and VideoConfiguration, as the issue describes. Review the linked Media Capabilities issue 160 for the ongoing audio discussion. Done means deciding which listed capabilities belong in the protocol and resolving whether to add, retain, or drop them; the issue names no repository files or tests.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Reviewing #225, I wondered how streaming protocol capabilities exposed in a streaming-capabilities-response mapped to capabilities defined in the AudioConfiguration and VideoConfiguration constructs in the Media Capabilities API.
For Video:
- The Open Screen Protocol has a
max-pixels-per-secondand asupports-rotationfield, neither of which match any property in the Media Capabilities API. When are these fields useful? If they are, should they be considered in the Media Capabilities API as well? If not, could they be dropped? - On top of HDR related properties that will be added to the Open Screen Protocol, Media Capabilities also has
scalabilityMode, which targets identifiers defined in WebRTC-SVC. Would that be worth adding to the Open Screen Protocol? - Media Capabilities also defines
hasAlphaChannel. That does not strike me as particularly useful in a remote streaming scenario though?
For Audio, Media Capabilities API also has:
samplerate. The Open Screen Protocol has [max-frames-per-second] for video capabilities, but no equivalent for audio.spatialRendering
Note that there is an ongoing discussion on these audio configuration capabilities in the Media Capabilities repo https://github.com/w3c/media-capabilities/issues/160.
- Lenguaje dominante
- Bikeshed
- Estrellas
- 115
- Forks
- 21
- Merge medio
- 5 h 2 min
- PR fusionados (30 d)
- 2
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/openscreenprotocol
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 18/100
w3c/openscreenprotocol#380 ·
-
osp-application
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
w3c/openscreenprotocol#377 ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 38/100
w3c/openscreenprotocol#376 ·
-
osp-application
Dificultad 2/5 1-3 horas Aptitud para principiantes 55/100
w3c/openscreenprotocol#375 ·
-
osp-application question
Dificultad 5/5 Más de una semana Aptitud para principiantes 30/100
w3c/openscreenprotocol#374 ·
Todos los issues de w3c/openscreenprotocol
Issues similares
-
auto:producer auto:security
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
fritzprix/libr-agent#2595 ·
Los mantenedores suelen responder en 1 día
-
Non-root first start logs "Base venv updated (stamp mismatch)" instead of the first-run messageAbiertoarea: infrastructure bug priority: low
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
snapotter-hq/SnapOtter#4573 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 83/100
-
comp: ssr comp: zones type: feature version: current (v17+)
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
angular/angularfire#3836 ·
Los mantenedores suelen responder en 3 días