W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2011

[whatwg] Recording interface (Re: Peer-to-peer communication, video conferencing, and related topics (2))

From: Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 29 Mar 2011 13:58:49 +0200
Message-ID: <4D91C979.2040301@alvestrand.no>
>> >  I also believe that the recording interface should be removed from this
>> >  part of the specification; there should be no requirement that all
>> >  streams be recordable.
> Recording of streams is needed for some use cases unrelated to video
> conferencing, such as recording messages.
Having a recording function is needed in multiple use cases; I think we 
all agree on that.
This is mostly a matter of style, which I'm happy to defer on.
>> >  The streams should be regarded as a control surface, not as a data channel; in
>> >  many cases, the question of "what is the format of the stream at this point"
>> >  is literally unanswerable; it may be represented as hardware states, memory
>> >  buffers, byte streams, or something completely different.
> Agreed.
>
>
>> >  Recording any of these requires much more specification than just
>> >  "record here".
> Could you elaborate on what else needs specifying?
One thing I remember from an API design talk I viewed:
"An ability to record to a file means that the file format is part of 
your API."

For instance, for audio recording, it's likely that you want control 
over whether the resulting file is in Ogg Vorbis format or in MP3 
format; for video, it's likely that you may want to specify that it will 
be stored using the VP8 video codec, the Vorbis audio codec and the 
Matroska container format. These desires have to be communicated to the 
underlying audio/video engine,  so that the proper transforms can be 
inserted into the processing stream, and I think they have to be 
communicated across this interface; since the output of these operations 
is a blob without any inherent type information, the caller has to 
already know which format the media is in.

Clearer?



>
Received on Tuesday, 29 March 2011 04:58:49 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:31 UTC