[mediacapture-handle] [Identity] Improvement: Expose contentHint (#35)

eladalon1983 has just created a new issue for https://github.com/w3c/mediacapture-handle:

== [Identity] Improvement: Expose contentHint ==
[Content Hints](https://www.w3.org/TR/mst-content-hint/) allow an application to instruct the encoder what type of content it could expect, and therefore might be the best type of encoding. It is up to the capturing application to deliver the content hint to the encoder. But it is the captured application which has this information. It would be good if there were a standard way for the capturee to **suggest** a content-hint to the capturer. If the capturer wishes, it can then use that suggestion.

That is:
1. Capturee calls `setCaptureHandleConfig` with a `config` that includes two fields, `suggestedContentHint`.
2. Capturer can ignore or use. If it chooses to use, then it sets `mst.contentHint` based on this. (Probably to the exact value suggested, but not necessarily.)

Suggested API:
dictionary CaptureHandleConfig {
  boolean exposeOrigin = false;  // Existing
  DOMString handle = "";  // Existing
  sequence<DOMString> permittedOrigins = [];  // Existing
  DOMString suggestedAudioContentHint = ""  // NEW
  DOMString suggestedVideoContentHint = ""  // NEW

And the algorithm for `setCaptureHandleConfig` can validate that the hints must be valid hints. (Doesn't have to - open for discussion).

dictionary CaptureHandle {
  DOMString origin;  // Existing
  DOMString handle;  // Existing
  DOMString suggestedContentHint;  // NEW

One thing we'll be adding here, is that we'll expose `captureHandle` on all track returned by `getDisplayMedia`. They'll be identical in some fields (origin, handle) and distinct in others (suggestedContentHint).

Please view or discuss this issue at https://github.com/w3c/mediacapture-handle/issues/35 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 14 March 2022 12:22:46 UTC