RE: updates to requirements document

Stefan,

  English is my native language and I don't  know the difference between
'capture' and 'record' either.  The requirements doc used 'capture' so I
kept it, and introduced 'record' because that's the term I normally use.
If we can agree on a single term to use, I'll gladly update the spec.


- Jim

-----Original Message-----
From: Stefan Hakansson LK [mailto:stefan.lk.hakansson@ericsson.com] 
Sent: Friday, July 13, 2012 9:06 AM
To: public-media-capture@w3.org
Subject: 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:16:29 UTC