- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Tue, 30 Aug 2022 15:46:21 +0000
- To: public-webrtc-logs@w3.org
To be clear, the idea of capturee trying to help capturer or UA with encoding seems fine. My questions are more related to whether/how this info gets exposed to/used by capturer. Some thoughts: 1. If there is tight coupling between capturer and capturee, this API is not needed, or more precisely this is just a small optimization, so low in priority. 2. In the short term, content hint can already be provided as part of the handle value. This might not be perfect in terms of separation of concerns, but early adopters can use this approach today in Chrome. Let's take the time to do the best design we can. 3. In another short term, the UA could use that content hint automatically (at least in RTCPeerConnection). 4. If there is no tight coupling between capturer and capturee, how is capturer supposed to interpret capturee content hint? Should it trust it or not? Maybe capturee input is only valid in a given context (say encoder is VP8) but is not good for other contexts (say encoder is H264). 5. In a world of VideoFrames, it seems this hint could be exposed as a VideoFrame metadata. 6. This API is not scalable as it is. As I said, just providing one content hint might not be enough once region capture is there. For instance, maybe capturee will only provide a content hint that is meaningful after cropping is done but some capturers may not do cropping. 7. I wonder whether `handle` should be an object (structure clonable or something like that) instead of a string. This way, the `handle` could contain some structured information (including CropTarget, content hints and so on). -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/mediacapture-handle/issues/35#issuecomment-1231847881 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 30 August 2022 15:46:27 UTC