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

From: "Narasimhan, Sam (SD-EX)" <[email-masked]>
Date: Thu, 14 Sep 2000 19:45:43 -0400

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: Fri, 15 Sep 2000 14:29:51 +0900

Dear Sam and all,

Additional comment:

When one content is delivered to different applications and environments,
such as set-top-box and mobile terminals, there are many differences on the
conditions. Network conditions, such as bitrate, error rate, jitter rate,
are
different in most cases. Profile@Level for set-top-box and tiny mobile
terminals are probably different. For some applications, non-MPEG-4 codec
may be used in combined. To adjust to these differences, we need to use
different set of parameters, such as bitrate, image size, refresh rate,
etc. at codec level anyway and different types of codec may be necessary.

> consumes precious bandwidth.
Considering above, having the same format ONLY at the RTP level may not help
the situation so much. It may be useful for some kind of mobile terminals
with Mbps bandwidth, error-free, large display size, but maybe it is not so
usual case. Or, such powerful terminal can easily implement SL-based
format.

>    payload would be picked up.
I think these streams are covered by SL-based payload. Why don't you use
this?

>     This is very minimal. The FEC proposal proposes the same type

I'm not convinced by this explanation. A VOP may be fragmented into many RTP
packets for error resiliency and/or low-delay requirements, and the size of
the RTP packet is relatively small. The fixed RTP header is compressed by
the header compression technique, but the extra field is not. The overhead
is still a serious problem since this RTP payload format may be used in very
low bitrate environment.

>     the ES payload is picked up.

Is there any guaranty on this? There were many concerns raised by both IETF
and MPEG experts on whether the ES payload receiver can decode SL payload
packet correctly only by adding the extra byte fields. We must be care not
to bring any danger to the implementers of ES payload format.

>     the length is private and left for future extensions.
Maybe I'm not a correct person to decide whether this change is small or
not. But again, we must be care not to bring any danger to the implementers
of ES payload format.

> can be accommodated. Thank you for your kind patience.
We are not so stubborn to reject all changes if it is really useful and
supported. Actually, many people helped us for the editorial clarification
of the Internet-Draft. However, the proposal of adding extra byte has many
serious problems:

- Clear disadvantage of the overhead.
- No guaranty to work..
- There are many concerns raised by both MPEG and IETF members.

How can we adopt such proposal?

Best regards,
Yoshihiro Kikuchi