Subject: Kikuchi-san proposal as subset of generic MPEG-4 formats

From: [email-masked]
Date: Thu, 14 Sep 2000 11:53:58 +0200

Dear all,

As promised in a previous email, I would like to review the problems
associated with making the proposal of Kikuchi-san a subset of the set of
generic formats that hopefully will be produced in La Baule. My assumption
is that there will be "generic formats" for several MPEG-4 streams, such as:
- MPEG-4 audio elementary streams (allowing for carriage of the remainder of
an SL header)
- MPEG-4 video elementary streams (allowing for carriage of the remainder of
an SL header)
- MPEG-4 system streams
For now, I would like to constrain the discussion to the first two, as these
two are also addressed in the proposal of Kikuchi-san. In the following
review I make a separation between video specific issues and audio specific
issues. The general issue of the additional bytes is discussed extensively
and I don't think there is a need to recap that here. The only clarification
that may be useful in this context is that the additional bytes can be used
to carry the remainder of an SL header in cases where needed, thereby
providing the same functionality as in the proposal of Civanlar et al.

Video specific issues

My proposal would be to use for the generic MPEG-4 video ES format exactly
the same payload type and names as Kikuchi-san. I also suggest to use the
same fragmentation rules. So from my perspective no need to change anything
specific to that.

Audio specific issues

Also for the generic MPEG-4 audio ES format I suggest to use the same
payload type, names and fragmentation rules as Kikuchi-san. With audio we
have the "LATM problem". However, with some pragmatism we may be able to
solve this. In Paris we agreed to allow for more than one access unit within
one SL packet. We could slightly modify this by allowing LATM as multiplex
structure within SL. (Note that the FlexMux provides a multiplex structure
on top of SL.) To indicate usage of LATM within an SL packet a currently
reserved bit in the SL header could be assigned. If we agree on his, then
the important question is whether we need also define carriage of MPEG-4
audio ES over IP without LATM. Perhaps not. LATM adds only little overhead
in case of a single large AU and for a small AU it is likely that LATM is
applied anyhow. A final remark on this issue: LATM is also used for carriage
of MPEG-4 audio ES over MPEG-2, pretty much consistent with usage of LATM
within SL and for transport over IP.

Along these lines I will propose specific wording changes to the proposal of
Kikuchi-san. Please comment if you disagree with the approach described. I
hope that my proposal for usage of LATM is not too big of a shock. In my
view it is an acceptable price to pay for compatibility with the proposal
from Kikuchi-san. And I believe such compatibility is important for the
success of MPEG-4 on the market place.

Best regards,

Jan