Re: Super-academic, highly-abstract meta-modelling time: The Media Path

On 15 February 2013 10:01, Mandyam, Giridhar <mandyam@quicinc.com> wrote:
> What about source settings that are directly manipulated by the end user?

This is a good question.

> For instance, what if the user is directly able to change the fillLightMode?
> If a track has already been initiated with a certain source setting and the
> settings change, then should this be an error condition?  I would think that
> some applications may be content to live with the end-user initiated
> settings change without destroying the track.  One possible approach is to
> define a settings change listener of some sort, which notifies the
> application when a settings change has occurred (due to end user
> interaction, or another track initialization, etc. – the cause of the
> settings change does not need to be exposed to the application).  Then the
> application can handle the settings change in any way it wants to  - treat
> it as an error, or continue the track with the new settings.

And it need not be "user action".  There could be any number of
reasons why the operating mode of the source is forced to change.
This is clearly the case where an 'onoverconstrained' event applies,
which might just be better defined as 'onsettingschange' so
applications can manage in-tab, cross-tab, cross-application and
user-initiated changes in the same fashion.  The big question is
whether the track ends, pauses, or continues with the modified (but
conflicted) settings.  I agree, the last option give the application
the choice, so I'd prefer to see that being the result.  A boolean
flag on an 'onsettingschange' event indicating that the settings
applied by this track are no longer all valid might be appropriate.
Or, on the other extreme, a collection of the settings that changed,
plus a collection of those that were broken.

This does have ramifications for some applications.  Any event is
going to appear after the change has taken effect.  It's possible that
some applications wont cope with these sorts of changes.  For example,
the SBC might crash if you change video resolutions mid-stream. I'd
like to hear screams before I added more API to deal with this sort of
corner case though.

Received on Friday, 15 February 2013 18:38:19 UTC