Subject: RE: comments on in-band-signaling proposal

From: [email-masked]
Date: Sat, 16 Sep 2000 12:47:29 +0200

This one did not came through yesterday, due to network problems
Sam, Kikuchi-san, others
While I am personally confident that it is possible to define a feasible and
good solution, I share some of the concern of Kikuchi-san. Within MPEG there
are far too many misunderstandings and disagreements to approve anything at
this time. MPEG clearly needs more time to identify the most desirable
approach.

Therefore I would like to suggest the following way forward :

1) The IETF proceeds with the Kikuchi-san draft without implementing the
in-band signaling proposal so as to meet the ITU deadline with minimum risk.
2) MPEG continues to consider the most desirable format for MPEG-4 ES and
other MPEG-4 streams.
3) In the La Baule meeting MPEG concludes its discussion by producing its
"generic" MPEG-4 over IP draft.
4) If MPEG at the La Baule meeting is confident about the feasibility and
usefulness of a forward and backward compatible solution using the
Kikuchi-san draft with in-band signaling, then MPEG will request IETF to
start the publication process of an "update" of the Kikuchi-san draft, that
will obsolete the current one.
5) In case of such "update", MPEG commits to neither change the "update" of
the Kikuchi-san draft, nor elements in the "generic MPEG-4 A/V ES" draft
that impact the forward and backward compatibility with the updated
Kikuchi-san draft.

Kind regards,

Jan

-----Original Message-----
From:	[email-masked] [mailto:[email-masked]]
Sent:	vrijdag, 15 september, 2000 02:15
To:	Jan vanderMeer; [email-masked]; [email-masked]
Cc:	[email-masked]; [email-masked];
[email-masked]
Subject:	RE: comments on in-band-signaling proposal

Dear Kikuchi-San and experts,

 I am coming from a world where content creators and
servers are very 'receiver-aware' and will not do anything
in the content creation that will crash receivers. In this
regard, the service providers who use the content want to
play this on as many receivers as possible and they are also
aware of the fact that receivers vary in their capabilities.
Service providers, on the other hand, will not send 2 separate
content streams to play on 2 receivers on the same wire as this
consumes precious bandwidth.

 2 examples of streams that one may want to play on receivers
that implement your draft are

1. A video ES that required CTS (in the RTP header) and DTS (which
   could be in the adaptation field). This may be needed for receivers
   that implement MPEG buffer models. This stream can play on
   receivers that implement your draft as it has a bigger buffer
   and does not need DTS, as long as your draft enabled these
   receivers to use the adaptation length field to offset where
   the video ES payload was picked up.
2. One may author SL packetized video where there was information
   in the SL header and this will be in the adaptation field. In addition,
   the authors will make sure that the video ES in the SL packet
   would be independently decodable by receivers that implemented your
   draft. This will require the ability to parse the first byte in
   the adaptation header and use it to offset where the video ES
   payload would be picked up.

 If your draft can accommodate this simple extension, then it will enable
the receivers to play more content from the future and it will enable
service providers to keep this in mind when they author MPEG-4 based
content in the future.

 Regards to your concerns,

1.  The overhead is 1 byte/RTP packet and this is a 6.25% addition
    to the 16 byte RTP header. If we sent 1 VOP per packet, then it
    is 30 bytes/sec (assuming 30 Hz video) or 240 bits/sec overhead.
    This is very minimal. The FEC proposal proposes the same type
    of overhead.
2.  The content authors will always make sure they follow all the
    other recommendations from your draft to make sure that the
    future content will play on receivers that implement the draft
    (such as sending data in decoding order, not splitting the headers
    etc). The only change from an implementation of today is the
    extra parsing of one byte before the ES payload to offset where
    the ES payload is picked up.
3.  The change to your draft would to be add 2 fields after the CSRC
    and before the video ES. These would be
    'adaptation length' and
    'length (if adaptation length is greater than 0)'.
    The semantics will say, the first byte after CSRC will contain the
    length of adaptation field. If this length value is zero, then the
    video payload will start in the next byte. Otherwise, the video
    payload will start after the number of bytes indicated in the
    adaptation length field. The content of the adaptation field after
    the length is private and left for future extensions.

 Jan Vandermeer may also have some suggested changes to the draft, if this
can be accommodated. Thank you for your kind patience.

Best Regards
Sam Narasimhan
Motorola

-----Original Message-----
From: Yoshihiro Kikuchi [mailto:[email-masked]]
Sent: Thursday, September 14, 2000 12:38 PM
To: IETF AVT
Cc: Zvi Lifshitz; Colin Perkins; Yoshihiro Kikuchi
Subject: comments on in-band-signaling proposal

Dear all experts,

The authors of the Internet-Draft have discussed the issue of
in-band-signaling proposal. We understand the importance of
interoperability, however, we do not believe the specific proposal of an
extra byte in the RTP header is a good solution. It is our common and firm
desire that any proposal will not degrade the original intention, purpose
and functionality of the RTP payload format.

Especially, the following points are important.

o Overhead caused by an extra RTP header
The in-band-signaling proposal will cause at least one byte overhead per
each RTP packet. Since this RTP payload format may be used in very low
bitrate applications such as mobile and analog modem, the overhead is a
serious problem. On the other hand, the ways suggested by Colin, Stephan,
etc. of using different payload types will not cause any overhead problem.

o Stability and reliability
As was pointed out by many, there is no guaranty that receivers of ES-based
RTP payload format can receive SL-based RTP packets correctly, even if the
extra byte in the RTP header is added. It is dangerous to adopt such
proposal at this moment without any guaranty. It is our strong desire that
only verified solution will be adopted in the RTP payload format
specification.

o Schedule
There is no specific description of changes about the proposal, so far. It
is hard to accept such proposal. Even if the proposal has some value
(although we doubt it), it should not be too late to adopt it in
SL-based proposal, by keeping backword compatibility with ES-based RTP
payload format.

These points are very important to keep the original functionality of the
proposal. Constructive comments are welcome, however, we cannot accept
any proposals to harm the original intention and functionality. By this
point, it is hard to accept the in-band-signaling proposal which causes
overhead problem and which is not well verified. It should be remarked that
the alternatives proposed by IETF experts will not cause any such problems.

Kind regards,
Yoshihiro Kikuchi
and authors of the Intenet Draft

----
        Yoshihiro Kikuchi

E-mail: [email-masked]
Corporate Research and Development Center
TOSHIBA Corporation
TEL: +81 +44 549 2288    FAX: +81 +44 520 1267

---

From: "Yoshihiro Kikuchi" <[email-masked]>
Date: Mon, 18 Sep 2000 19:39:16 +0900

Dear Jan and all,

Following suggestion 1, the authors will produce an updated Internet-Draft
of MPEG-4 Audio/Visual RTP soon with reflecting comments raised and agreed
during the WG last call period. It does not included in-band signaling
proposal.

It is too early for us to comment on suggestions 2-5, because we have not
seen detailed proposal. In any case, we cannot accept any disadvantage
(overhead, efficiency, risk, documentation, ...) compared to the current
spec. We should also be care that we will not fall into "an MPEG only
solution".

But if we can keep on these, maybe we will have a good solution in the end.

Kind regards,
Yoshihiro Kikuchi

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Saturday, September 16, 2000 7:47 PM
Subject: RE: comments on in-band-signaling proposal