On Wed, Mar 16, 2011 at 12:11 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Take video conference as an example: the stream for the main display (e.g. representing the active speaker) might use a very resource consuming codec/format/resolution, while there can be a number of streams for small "thumbnail" displays that require much less resources.
Just to be sure I understand the example, the assumption here is that the "Active speaker" stream can switch to a different speaker, so that there would be a renegotiation for both the previously "Active speaker" and the newly selected one, right? I think this is pretty workable, provided we don't have to restart the negotiation from the beginning. If there are multiple known good feature sets for each speaker, switching among them isn't such a problem. It's easier, obviously, if it is a straight swap (high-end codec moves from speaker A to speaker B). It's a little harder if the codecs available for B are different, but it still works reasonably well if the resource consumption is similar. But if switching from speaker A to speaker B forces a complete renegotiation of all streams because speaker B's requirements are very onerous, we can expect some impact on app performance.
We also need to ensure that we don't make life to difficult for the web app developer, by mandating him/her to browse through a potentially large list of alternatives before requesting streams.
My personal concern is more with complexity than size. If there is a large list of capabilities, all to the good. But if the complexity of the feature sets is high or the interaction among them high, you can end up with least-common-denominator behavior pretty easily. There are some ways to improve that--CONNEG allows for named features sets, for example, and well-known names for common clusters could significantly speed processing--but we don't want to make computing the optimal set intersection a major drain on time or resources.
So, I agree that being able to query for different alternatives is a good thing, but it should also be possible for the web app to simply request an explicit stream set (based on web app logic and/or an offer received from the remote peer), which is then either accepted or rejected by the browser. And, if rejected, it would then be good if the browser provided some information on why it was rejected. The web app could then either query for alternatives, OR simply try to request a new stream set (based on the error information provided by the browser for the previous request).
I really don't think the browser providing information on why it was rejected is all that useful; we don't want these to be consumed by humans. I personally think it is better if the web app passes down a list of requested feature sets and lets the browser compute the best intersection. You could manipulate that by having the web app decompose the offers itself and pass them down one by one in the order it felt was appropriate, taking the first match. There's no API difference there, it's just a bunch of serial one-possibility offers rather than a full set. But the typical APP is going to want "give me the best I can get", at least at my guess, rather than wanting to keep on top of what the preferred set intersections are itself. regards, Ted Hardie
Regards,
Christer