RE: terminology (was: updates to requirements document)

> This is similar to how
> the HTML parser handles incoming bits from the wire before it determines what
> a page's encoding is.

Sorry, bad example. I meant to say that it's similar to how the HTML parser must wait to execute an inline script block until all the bits that make-up that script tag have been received on the network--it can't process the script until the data for that action is completely received. Similarly, a JavaScript-implemented frame decoder might have to wait until the next "chunk" of data is available before it could fully process a partially-received frame.

> -----Original Message-----
> From: Travis Leithead [mailto:travis.leithead@microsoft.com]
> Sent: Friday, July 13, 2012 11:59 AM
> To: Jim Barnett; Stefan Hakansson LK; public-media-capture@w3.org
> Subject: RE: terminology (was: updates to requirements document)
> 
> Likewise, "record" and "capture" are synonyms to me too. In general, it seems
> like there are some other words we could use to be more precise, since we
> might be having misunderstandings based on terminology, which would be
> unfortunate.
> 
> My understanding of the original proposal for recording (see
> http://www.w3.org/TR/2011/WD-webrtc-20111027/#methods-3) was that you
> could call a record() API to start _encoding_ the camera/mic's raw data into
> some binary format. Here I think the words "capture" and "record" both seem to
> refer to this process. At some point in the future you could call
> getRecordedData() (see http://www.w3.org/TR/2011/WD-webrtc-
> 20111027/#methods-5) which would then asynchronously create a Blob object
> containing the encoded binary data in some known format (blob.type would
> indicate the mime type for the encoding whatever the UA decided to use -- there
> was no control or hint mechanism available via the API for encoded format
> selection). I believe the returned Blob was supposed to be a "complete" file,
> meaning that it's encoding contained a definitive start and end point, and was
> *not* a binary slice of some larger file. In other words, the returned Blob could
> be played directly in the html audio or video tag, or saved to a file system for
> storage, or sent over XHR to a server.
> 
> So, when you mentioned the word "chunks" below, were you referring to the
> idea of calling getRecordedData() multiple times (assuming that each
> subsequent call reset the start-point of the next recording--which is actually
> *not* how that API was specified in fact)? Rather than "chunks" I think of these
> as completely separate "capture" sessions--they are complete captures from
> end-to-end.
> 
> When I think of "chunks" I think of incomplete segments of the larger encoded
> in-progress capture. The point at which the larger encoded data buffer is sliced
> (to make a "chunk") might be arbitrary or not. I think that is something we can
> discuss. If it's arbitrary, than the JavaScript processing the raw encoded "chunks"
> must understand the format well-enough to know when there's not enough data
> available to correctly process a chunk, or where to stop. This is similar to how
> the HTML parser handles incoming bits from the wire before it determines what
> a page's encoding is. If we decide that the chunks must be sliced at more
> "appropriate" places, then the UA's must in turn implement this same logic given
> an understanding of the encoding in use. As an implementor, it seems like it
> would be much faster to just dump raw bits out of a slice arbitrarily (perhaps as
> quickly as possible after encoding) and let the JavaScript code deal with how to
> interpret them. In this case, the returned data should probably be in an
> TypedArray of some form.
> 
> 
> 
> > -----Original Message-----
> > From: Jim Barnett [mailto:Jim.Barnett@genesyslab.com]
> > Sent: Friday, July 13, 2012 6:16 AM
> > To: Stefan Hakansson LK; public-media-capture@w3.org
> > Subject: 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 19:07:29 UTC