Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format

From: John Lazzaro <[email-masked]>
Date: Sat, 17 Jun 2000 10:59:03 -0700

Hi everyone,

	I had a few quick comments about
draft-ietf-avt-rtp-mpeg4-es-01.txt, with respect to using it for MPEG
4 Structured Audio (ISO/IEC 14496-3 sec 5) content. For those
unfamiliar with SA content, its a combination a tokenized C-like
program, contained in a StructuredAudioSpecificConfig, and
SA_access_units that launch processes (called instrs) or change local
and global variables (either in a direct way, like "change a to 12",
or an indirect way, like "fill this table with one cycle of a harmonic
series with these weightings").  The StructuredAudioConfig can also
contain an arbitrary amount of SA_access_unit-like data packed within
it. For a gentle introduction to SA see:

http://www.cs.berkeley.edu/~lazzaro/sa/

	While I've read over draft-ietf-avt-rtp-new-07.txt as well as
a recent draft of the Systems FCD for ISO/IEC 14496-1, I'm not at all
a transport guy (but I do see Larry Rowe in the hallway sometimes :-) --
these are just a few things that caught my eye as I read through
draft-ietf-avt-rtp-mpeg4-es-01.txt:

[from page 19, 6.4 of draft-ietf-avt-rtp-mpeg4-es-01.txt]

> The followings are some examples of the media representation in SDP:
>
>  For 6 kb/s CELP bitstream (the audio sampling rate of 8 kHz),
>    m=audio 49230 RTP/AVP 96
>    a=rtpmap:96 MP4A/8000
>    a=fmtp:96 profile-level-id=9;object=8;cpresent=0;config=9128B1071070
>    a=ptime:20

For SA, the string after "config=" (i.e. the
StructuredAudioSpecificConfig) can be quite large (two example streams
on SA primary author's Eric Scheirer's website are 27 kbytes and 1.7
Mbytes respectively). Rare will they be under a kbyte. Is SDP happy
handling data chunks this large?

Also, a large part of many config blocks will be quite predictable --
uncompressed tokenized representations of a program in a C-like
programming language. Does this have any cryptographic consequences?

[from Page 1, 1.3 of draft-ietf-avt-rtp-mpeg4-es-01.txt]

> Furthermore, if the payload of a packet is a single audio frame, a packet
> loss does not impair the decodability of adjacent packets. Therefore, a
> payload specific header for MPEG-4 Audio is not required as same as one
> for the other audio coders.

If I understand this paragraph correctly, for SA_access_units this isn't
true in general. For example, an SA_access_unit may set a global variable
to a new value, which is then references throughout the audio content
to make a macro change in the performance (for example, set the 
amplitude level of the audio output of an instrument). So in this sense,
an uncorrected error in an SA_access_unit can essentially destroy all
audio produced after the error, for the rest of the performance.

							--john lazzaro

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

---

From: "Toshiyuki Nomura" <[email-masked]>
Date: Mon, 19 Jun 2000 17:27:30 +0900

Dear John and all,

Thanks for your comments.

> handling data chunks this large?

I think it is not happy for SDP to handle such large data. Such
large data should be transmitted by the other out-band means.
Otherwise, the config data for SA should be transmitted by
in-band mode, where the config data is multiplexed with the audio
data into the RTP payload, due to the large size of the SA config data.
As described in draft-ietf-avt-rtp-mpeg4-es-01.txt,
this can be done by setting the cpresent flag to 1.

If my understanding is correct, I would like to propose that
the config for SA is restricted to be transmitted by the above
in-band mode.

> audio produced after the error, for the rest of the performance.

I think re-transmission can be applied. If an SA_access_unit makes
a change which influences the following SA audio data, the SA_access_unit
indicating such changes should be transmitted repeatedly.
The number of repetition will be dependent on the network condition.

I would like to add some sentences to the current I/D in order to clarify
error sensivity for SA.

Best Regards,

Toshiyuki Nomura, NEC