- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Tue, 29 Mar 2011 13:58:49 +0200
>> > 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