- From: Davy Van Deursen <davy.vandeursen@ugent.be>
- Date: Thu, 20 Aug 2009 07:55:37 +0200
- To: "'Silvia Pfeiffer'" <silviapfeiffer1@gmail.com>
- Cc: <public-media-fragment@w3.org>
>-----Original Message----- >From: public-media-fragment-request@w3.org [mailto:public-media- >fragment-request@w3.org] On Behalf Of Silvia Pfeiffer >Sent: Thursday, August 20, 2009 5:24 AM >To: erik mannens >Cc: public-media-fragment@w3.org >Subject: Re: ACTION-84: Summarize the info from Jean Pierre, and mail it >to the group [SMPTE MXF editUnit Spec] > >Hi all, > >In yesterday's teleconference, Raphael pointed to this email with the >question whether we should add a generic addressing scheme for >"editUnit"s. > >I can see how editUnits are very important to container formats. In >fact, in Ogg we have a thing called granules which represents the same >concept. MXF has obviously defined editUnits as their word to use for >this. > >editUnits are the finest granularity at which an encoded media stream >can be dealt with without having to decode it. So, editUnits give us >for a particular codec in a particular container format and with a >particular encoding setting the lowest resolution that this resource >is capable of delivering. > >For example: a wav file generally encodes audio without compressing, >so you can access each audio sample individually. If a particular file >was encoded at 44100 Hz, then your editUnit resolution is in theory >0.000023sec. A video stream. encoded in as mjpeg (just for simplicity) >and at 25 fps would have a editUnit resolution of 0.04sec. This >already poses another problem: what is the combined editUnit of a >container that has both an audio and a video track? > >So, if we are considering addressing something by "t=editUnit:34,500" >I cannot see how that will ever work. > >Firstly, the editUnit is dependent on the resource format and the >particular encoding parameters used for that resource. If you >re-encode the resource with, e.g. a higher temporal resolution, your >editUnit changes and your URL is not correct any more. > >Then, I don't see how we can reconcile an editUnit across multiple >track. For Ogg, we are keeping the editUnit information in the >skeleton track for each audio, video, and annotation track separately. > >Finally, what would such an addressing unit give a user or even a >program? editUnit has no semantic meaning at all. It is a deeply >codec-specific information that has no meaning outside the real of >codecs. > >So, I am very much against introducing such an addressing means. +1, editUnits are indeed different for different tracks, and I don't think we want to be able to specify a time range per track. Best regards, Davy -- Davy Van Deursen Ghent University - IBBT Department of Electronics and Information Systems Multimedia Lab URL: http://multimedialab.elis.ugent.be > >Cheers, >Silvia. > >On Wed, Jul 15, 2009 at 8:38 PM, erik mannens<erik.mannens@ugent.be> >wrote: >> Dear all, >> >> >> >> >> >> Summarization of SMPTE 377M-2004 (MXF File Format spec) editUnit >> >> >> >> Editable unit: The smallest portion of the essence container which can >be >> edited such as a field or frame. >> >> >> >> Edit rate: A rational number that specifies the units used to specify >the >> duration of components in a track; the edit rate is the number of >units that >> equal one elapsed second. In a track which describes an essence >container, >> the edit rate is usually chosen to be the number of editable units per >> second. >> >> >> >> Edit unit: A period of time equal to 1/(edit rate), thus mostly >1/frameRate >> or 1/sampleRate (which is the smallest time fraction per frame or >sample, >> e.g. 1.001/60 or 1/25 or 1/41000) >> >> >> >> timestamp: editUnit * value (integer) = timepoint corresponding >accurately >> to one sample or frame within a media resource >> >> >> >> >> >> An editUnit is usually a field for video, but could equally well be a >frame >> (comprising 2 interleaved fields, or perhaps a single progressive >frame). An >> editUnit for an audio-only application could be an audio frame. >There’s a >> big resemblance to MPEG-7’s mediaTimeUnit (e.g. mediaTimeUnit=”PT1N25F” >> which means “1 fraction” (1N) knowing that there are “25 fractions/s” >(25F)) >> >> >> >> There are different approaches to representing the editUnit e.g. float >or >> fractional. >> >> >> >> The editUnits are now also being used in all EBU metadata >specifications and >> it has also been adopted by IPTC for NewsML-G2. >> >> >> >> Looking at the structure defined in our current MFWG draft, I don't >know if >> we want to simplify it by removing the references to different >timecoding >> schemes by just adding the editUnit. In IPTC, for NewsML-G2, it was >decided >> to allow both as well as npt (with 3 digits after the "." for >milliseconds). >> >> >> >> >> >> Sincere greetings, >> >> >> >> Erik Mannens >> >> >> >> Project Manager >> >> >> >> Gaston Crommenlaan 8 bus 201 >> >> B-9050 Ledeberg-Ghent, Belgium >> >> >> >> T: +32 9 331 49 93 >> >> F: +32 9 331 48 96 >> >> M: +32 473 27 44 17 >> >> >> >> http://multimedialab.elis.ugent.be >> >>
Received on Thursday, 20 August 2009 05:56:29 UTC