- From: cynthia <notifications@github.com>
- Date: Wed, 31 Oct 2018 13:32:41 +0000 (UTC)
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Wednesday, 31 October 2018 13:33:03 UTC
Hey all, Thanks for filing this issue. We took it up during our Paris F2F. Apologies that it took so long. I had a question about how this could be use to test capabilities in a multiple media stream context. For example, can we understand if it's possible to efficiently decode more than one video stream at once? Or get a maximum number of streams/channels/densities at which the client would hit limits? This case could come up in an RTC scenario. There may be cases where decode won't be smooth when you have two decoders or a encoder and decoder pair running, for example. We also had questions about naming and types of the returned capabilities, specifically `smooth` and `powerEfficient`. These names imply a guarantee - despite what you've already written about how they are not. Have there been any alternative names considered? Curious if this can be addressed somehow? (We ballbrainstormed ''`janky` or `powerInefficient` as poor choices, but with the logic inverted.) Thanks again, and looking forward to hearing back. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/218#issuecomment-434687955
Received on Wednesday, 31 October 2018 13:33:03 UTC