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.

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 03:24:36 UTC