- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Tue, 19 Aug 2014 21:46:47 +0200
- To: public-media-capture@w3.org
On 08/19/2014 04:57 PM, cowwoc wrote:
> On 19/08/2014 10:40 AM, Harald Alvestrand wrote:
>>> You also seem to assume that people will specify constant values as
>>> opposed to calculating the desired value programmatically. That's
>>> not necessarily true. I may very well decide to create a dynamic
>>> viewport depending on what is going on in my application at a given
>>> time and its aspect ratio might change across runs (this is even
>>> more true in the context of desktop web browsers where the window
>>> size changes on a regular basis).
>>
>> In that case, it's even more important that the user (programmer) be
>> trained to give the system the chance to make approximations - if
>> aspect ratios are dynamic, they will very often be impossible to hit
>> exactly, due to things like granularity of codec macroblocks
>> (typically 16 pixels).
>>
>> And it's even less likely that the epsilon will matter in practice.
>
> Discussing this in more detail, how does the API enable developers to
> implement this use-case?
Which use case? The one you described above, or something else?
> Certainly a developer will want the biggest video box smaller than [X,
> Y] and then he might have preferences in terms of the aspect ratio.
I hesitate to use the word "certainly".
> For example, one developer might prefer widescreen aspect ratios while
> another might prefer 4:3 (depending on say ... whether they are
> broadcasting multimedia or screen sharing a remote desktop). How does
> the API allow the developer to express such constraints?
Even in the first use case posited - dynamically changing aspect ratio
of display window - there are multiple things the developers could want.
Some developers want the display to tell the generator what to generate.
Once you have the stream, and the viewport size changes, it would be
logical to call
videotrack.applyConstraints({aspectRatio: { exact: <current aspect ratio> })
and the browser would propagate the information and let a decision be
taken on how to satisfy the criteria - if it can't, it won't; there's a
high risk that this would lead to an overconstrained event.
Some developers want the same thing, but would rather have the receiver
deal with any mismatches (by setting the relevant properties on the
<video> tag - <video> already has a pretty full set of capabilities
specified for this purpose; it would do
videotrack.applyConstraints({aspectRatio: {ideal: <current aspect ratio> })
And some developers care more about other things, and wouldn't set the
constraint at all.
--
Surveillance is pervasive. Go Dark.
Received on Tuesday, 19 August 2014 19:47:18 UTC