Re: updates to requirements document

Milan,

isn't your core proposal that we should have a requirement that allows 
recording of audio (and it would apply to video as well I guess) to a 
files, i.e. some kind of continuous chunked recording?

I think that would make sense (and that was how the original, 
underspecified, recording function worked IIRC), and that those chunks 
would be possible to use as source in the MediaSource API proposal (even 
if my number one priority would be that those files would be possible to 
use as a source to the audio/video elements).

I do not understand why we would add words about "encoded" and so on 
though. We don't use that kind of language in any other req, why here?

Stefan

PS English is not my native language, I would be very glad if someone 
could explain the difference between "capture" and "record" for me - I 
must admit I do not know the difference. Ideally I would like one word 
meaning something like "using a mike/cam to start producing data" and 
another one for "storing that data to a file".


On 07/11/2012 06:04 PM, Young, Milan wrote:
> Sorry if I'm missing context, but is there counter proposal or are you just warning us that this is a long haul?
>
> Thanks
>
> -----Original Message-----
> From: Timothy B. Terriberry [mailto:tterriberry@mozilla.com]
> Sent: Wednesday, July 11, 2012 8:50 AM
> To: public-media-capture@w3.org
> Subject: Re: updates to requirements document
>
> Randell Jesup wrote:
>> And...  Defining the associated control information needed for
>> decoding is a significant task, especially as it would need to be
>> codec-agnostic.  (Which from the conversation I think you realize.)
>> This also is an API that I believe we at Mozilla (or some of us)
>> disagree with (though I'm not the person primarily following this; I
>> think Robert O'Callahan and Tim Terriberry are).
>
> More than just codec-agnostic. It would have to be a) flexible enough to support all the formats people care about (already challenging by
> itself) while b) well-defined enough to be re-implementable by every vendor in a compatible way. This leaves you quite a fine needle to thread.
>
> I don't want people to under-estimate how much work is involved here.
>
>

Received on Friday, 13 July 2012 13:06:36 UTC