- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Thu, 6 Dec 2012 12:13:33 +0100
- To: Harald Alvestrand <harald@alvestrand.no>
- CC: public-media-capture@w3.org
On 2012-12-06 12:10, Adam Bergkvist wrote:
> On 2012-12-06 12:03, Adam Bergkvist wrote:
>> On 2012-12-05 17:38, Harald Alvestrand wrote:
>>> Changing subject as always....
>>>
>>> thanks a lot!
>>>
>>> q: with this interface, isn't the division into a set of video tracks
>>> and a set of audio tracks simply an implementation detail that the API
>>> doesn't have to spec?
>>>
>>> IE it would be equally valid if there was only one bunch of tracks, and
>>> the get*tracks functions just grepped through it.
>>>
>>> I like having implementation details be unobservable....
>>
>> I simply picked the two-bucket-approach as a way to describe the
>> behavior. Yes, it would be equally valid to have one bucket and filter
>> it to provide the output to the different get* methods. Perhaps that
>> approach would be easier (=require adding slightly less spec text) to
>> extend with new track types.
>>
>> I general, I see the algorithms as: if you follow the algorithm you are
>> compliant. Also, if you implement this in an other way that produces the
>> exact same result as following the algorithm; you're also compliant.
>
> Looking at the updated spec text, the two sets are pretty much always
> references together ("audio track set" or "video track set"). It's only
> in the get* functions they're treated separately. This means that a
> single set would be cleaner. It's a huge change so I'll send out a new
> slide set after lunch.
I meant to say that it's _not_ a huge change.
/Adam
Received on Thursday, 6 December 2012 11:14:03 UTC