Subject: Re: LATM specified in a public MPEG document?

From: John Lazzaro <[email-masked]>
Date: Fri, 22 Sep 2000 12:01:06 -0700

> well, this is a show-stopper.  we cannot base a standard on something 
> that is not publicly defined.

Oh, this is just temporary -- eventually anyone can send a
check to MPEG and buy the FDIS that defines LATM, which I think would
meet the requirement of "publicly defined". Usually the FCD's are posted
on publically-available websites like this one:

http://sound.media.mit.edu/mpeg4/audio/

but you'll notice the last FCD is Dec 1999 (scroll down to MPEG 4) which
is pre-LATM. So in that sense, I'm in the dark as someone outside of
MPEG trying to comment on an I-D that references something not in a 
publically available working document ... 

-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu     www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------

---

From: John Lazzaro <[email-masked]>
Date: Mon, 25 Sep 2000 11:00:30 -0700

> By the way, could you let me know what is "use immediately semantics"?

From 5.5.2 of 14496-3:1999(E), starting at the bottom of page 20:

  The Structured Audio access unit contains real-time
  streaming control information to be provided to a
  running Structured Audio decoding process. It may
  contain as many control instructions as desired and as
  permitted by the available bandwidth. It shall not
  contain new instrument definitions; the orchestra
  configuration is fixed at decoder start-up. It may
  contain score lines, MIDI events, and new sample
  data. When provided as part of an access unit, the
  score line is not required to contain a timestamp.
  When has_time is cleared in the score_line class, the
  event is dispatched immediately according to the rules
  in subclause 5.7.3.3.6. Score lines without timestamps
  are not responsive to orchestra tempo changes. 

  Annex 5.E discusses when the random access point
  flag, conveyed in the Access Unit packaging in the
  Systems specification, may be set. 

The "score line is not required to contain a timestamp"
section is what I meant by "use immediately semantics".

> I think such limitation should not be described in the LATM
> itself definitions. 
> This is because these matters depend on the functions of the
> transport layer.

I guess the issue I'm trying to bring up is this: 

[1] Let's say you're sending an SA_access_unit using MIDI,
whose semantics are NOT "use immediately semantics". If
so, you're dependent on a timestamp to say "when to fire"
supplied from elsewhere. Note this means the timestamp 
has two bounds on it -- too early and the note fires too
early, too late and the note fires too late. The precision
of the timestamp becomes the precision of the performance --
too sloppy and things sound bad.

[2] If I understand the earlier info on LATM correctly (remember,
I don't have access to the spec), LATM doesn't supply timestamps.

[3] So, whatever packetization is used (for example, RTP), needs
to supply this timestamp -- however, the accuracy requirements
for this timestamp (as described in [1] above) is sufficiently
unusual for someone used to "natural audio" codecs, that an 
explicit heads up may be in order, in both the LATM and the
RTP documents.

Hope this helps ...

						--john lazzaro