AW: Abstract and Introduction draft for API document

Dear David, all,

thanks for your comments. I agree, setters do not make sense for the technical properties of the media file. In addition, I think we should discuss whether we want to include setters at all in the first draft, given the many doubts around implementing them.

Concerning numeric properties that vary over time: I think they should be defined to return the average of the fragment, you can still ask for shorter segments if you need the information in more detail.

Best regards,
Werner

________________________________________
Von: public-media-annotation-request@w3.org [public-media-annotation-request@w3.org] im Auftrag von David Singer [singer@apple.com]
Gesendet: Dienstag, 06. Oktober 2009 01:17
An: public-media-annotation@w3.org
Betreff: Re: Abstract and Introduction draft for API document

Hi guys

   Section 2.2 defines "API for Technical Properties", includes
property setters

RESULT setFrameSize(object framesize);
RESULT setCompression(DOMString compression);
RESULT setDuration(unsigned long duration);
RESULT setFormat(DOMString format);
RESULT setSamplingrate(unsigned long samplingrate);
RESULT setFramerate(float framerate);
RESULT setBitrate(float bitrate);
RESULT setNumTracks(unsigned short numtracks);

although these properties are all intrinsic to an encoded media file.
It doesn't seem right to have setters for these.

Also, frameRate might be variable.  Are we supposed to report the
long-term average, the frameRate 'at' the current playback position,
or what, if it's not constant?
--
David Singer
Multimedia Standards, Apple Inc.

Received on Tuesday, 6 October 2009 07:48:41 UTC