W3C home > Mailing lists > Public > public-media-fragment@w3.org > August 2009

RE: ACTION-84: Summarize the info from Jean Pierre, and mail it to the group [SMPTE MXF editUnit Spec]

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>
Message-ID: <000f01ca215a$d78b3c00$86a1b400$@vandeursen@ugent.be>
>-----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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:34 GMT