- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Fri, 20 May 2022 09:35:32 +0000
- To: public-webrtc-logs@w3.org
> > And all of this wonderful complexity is in the service of...? > > @eladalon1983, when looking at this API... Thank you for this message, @youennf. I know all messages take effort, and I value your time. Alas, having read this message three times, I still cannot find in it an answer to my original question. Namely - what is this [incredible complexity](https://github.com/w3c/mediacapture-region/issues/17#issuecomment-1132095029) serving? I continue to await an answer. I shall now answer your question, but I'd appreciate it if you did not forget to answer mine. > Is it loosing 1 or 2 frames or one second of frames? Being slower to start, stop, or change the crop target, is unfortunate. An application that decide to change the crop-target will often pause the track until it is informed that all subsequent frames are cropped to the new target. This can be noticeable to both the local user as well as remote users. This visible disruption should be minimzed. > And start cropping + store them in a round robin cache to optimise the regular cases. Caching is a well known optimisation tool so I think we can qualify this as a simple approach. A render-to-render communication channel would have to be produced to support the case of a cahce-miss. A case you expect to happen [0.01% of the time](https://github.com/w3c/mediacapture-region/issues/17#issuecomment-1129888809). But this backup would have to be set up every time. That complexity is not warranted. (And please do NOT read this message as an acknowledgement that any of the rest of your proposed solution works.) -- GitHub Notification of comment by eladalon1983 Please view or discuss this issue at https://github.com/w3c/mediacapture-region/issues/17#issuecomment-1132690689 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 20 May 2022 09:35:34 UTC