Re: Early Holiday Present: Settings API version 6

On 12/13/2012 07:48 PM, Martin Thomson wrote:
> On 13 December 2012 04:32, Stefan Hakansson LK
> <stefan.lk.hakansson@ericsson.com> wrote:
>> Overall I think this looks good.
>
> Likewise, and I also agree that we need to get this merged soon; the
> overhead of having two parallel specifications isn't fair on anyone
> (Travis most of all).
>
>> 3.2.1: It is said that "stop()" stops the source. But what if other tracks
>> depend on the same source? Should it no be that stop detaches this track
>> from the source and ends this track; and that a source is stopped if no
>> tracks are attached.
>
> stop() on the source makes the most sense.  Detaching all associated
> media streams from their sinks might cause the source to scale its
> output down to nothing...

Having stop() on the source makes sense to me.

>
>> Section 6.1
>> -----------
>> First example: I look first on the local part only. In the example the two
>> local  sinks are served by two different MS's. What is not clear to me is:
>> what happens if the app sets the resolution to 1920*1080 on the MS serving
>> sink A followed by setting it to 320*200 on the MS serving B? Is it the
>> latest setting that takes effect, or is it the most demanding or latest or
>> what? And, what if the track to which the setting was applied is ended, or
>> not consumed, what happens?
>
> I have no real concern with this other than the effect it might have
> on implementations that have to perform an intersect operation at the
> source to determine what it should do.
>
> It would be easier, overall, if the constraints did apply to the
> source and that the constraints that were set on a track were only
> held in situ until a source was found, after which the
> constraints/settings APIs on the track would just write through to the
> source.
Agree.
>

Received on Thursday, 13 December 2012 19:03:16 UTC