Re: [w3ctag/design-reviews] Media Capabilities (#218)

Hi! Apologies for the delay. I have a pile of excuses, but it all boils down to - buried in mail backlog. Sorry, and thank you so much for your patience.

> Its not easy to know with current API shape and I haven't thought much about ways the API could be changed for this use case. If you wanted to show 2 videos of same resolution you could approximate by doing a query that doubles the framerate. For sw codecs this is decent. For hw codecs it will depend how the hw resources are divided (e.g. by time slice vs by playback). AFAIK platform decoder APIs don't often surface parallel session limits up front, so this would involve some guessing/learning even for implementers (not a deal breaker).

This came from the possibility of an application such as this: https://viewsync.net

Are there any native APIs that surface this information up that could be used on constrained devices? (e.g. Mobile OSes come to mind) If so, noting that it might be recommended to make use of the plumbing done there as a non-normative note could improve the usefulness of this API.

The same limitation most likely exists in WebRTC, and if I understand the situation correctly application rely on blunt UA sniffing to determine if it is a desktop or a mobile/embedded environment and either just drop dead or only show a single video stream (or none), which is suboptimal. (I recall appear.in not being very nice to Safari, for example)

> We could prefix the names with "ideally" or "typically"... I tend to favor the shorter names though. I expect sophisticated users of the API to understand that nothing is ever guaranteed in media ;).

I actually do not have strong opinions on this; @travisleithead may have more to say on this.

> Also, we have updated (diff, PR) the spec for decodingInfo() to allow callers to describe encrypted media. This doesn't really change the API shape nor have implications existing callers. It merely adds new optional fields to the input dictionaries and new algorithm steps to process those inputs. The motivations for this are described here in the explainer. Please let me know if mentioning those additions here is sufficient to trigger review.

This can be lumped together with the same review; I'll look at the changes and post another comment. This time not two months down the road!

An extra question that came to mind is whether capabilities for a remote playback device should be accessible (given that a native mechanism exists, this I need to do some homework on) in a similar manner: https://w3c.github.io/remote-playback/

-- 
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-453094722