Subject: comments on in-band-signaling proposal

From: "Yoshihiro Kikuchi" <[email-masked]>
Date: Fri, 15 Sep 2000 04:38:04 +0900

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: Zvi Lifshitz <[email-masked]>
Date: Fri, 15 Sep 2000 09:34:03 +0200

[Narasimhan, Sam (SD-EX):]

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.

[Reply:]

The jitter on IP network is such that practically receivers may always assume CTS=DTS for implementation of the buffer model.

[Original message:]

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.

[Reply:]

There is header compression. I think Kikuchi-san mentioned that, along with few other good arguments.

Regards,

z
soon the whole world will STREAM
==================================================================
Zvi Lifshitz				Phone +972(2)679-4788
[email-masked]			Fax +972(2)679-4789
Optibase Ltd.				Mobile: +972(53)461-787
http://www.optibase.com		US voice mail/fax  +1(206) 888-4149
Send SMS from: 			http://isend.cellcom.co.il/English/Login.htm ==================================================================
> Come see us at:
Streaming Media Europe Earls Court Centre, Booth # 628, London, October 10th-12th, 2000

---

From: Franceschini Guido <[email-masked]>
Date: Fri, 15 Sep 2000 08:51:41 +0200

Sorry MPEG friends,

but I fully support Kikuchi-sun.

At least until I see a proposal that does not address just the extra-byte
detail, but solves the real problem (negotiation). So that everybody can
convince himself that there are different ways to fit the requirement at the
level of RTP packets ...
Remember, when using the SL mapping an 'old' receiver has currently no way
to know the media being carried. It could even be BIFS !
[ps: in addition there is a need to clean-up the LATM issue, but this is
orthogonal IMHO.]

Best regards
Guido

> ----------
> From: 	Yoshihiro Kikuchi[SMTP:[email-masked]]
> Sent: 	Friday, September 15, 2000 7:29 AM
> To: 	Narasimhan, Sam (SD-EX); IETF AVT; [email-masked]
> Cc: 	Zvi Lifshitz; Colin Perkins; 4on2andIP-sys; Yoshihiro Kikuchi
> Subject: 	Re: comments on in-band-signaling proposal
> 
> 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.
> 
> >  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.
> >
> 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.
> 
> >  2 examples of streams that one may want to play on receivers
> > that implement your draft are
> >
> > 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.
> >
> I think these streams are covered by SL-based payload. Why don't you use
> this?
> 
> >  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,
> >
> 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.
> 
> > 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.
> 
> 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.
> 
> > 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.
> >
> 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.
> 
> >  Jan Vandermeer may also have some suggested changes to the draft, if
> this
> > 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
> 
> > -----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,
> >
> >

---

From: Zvi Lifshitz <[email-masked]>
Date: Sun, 17 Sep 2000 12:07:26 +0200

With the exception that I didn't understand 5, this is ok with me.

Regards,

z
Optibase Ltd.				GSM: +972(54)461-787

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

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

---

From: "Narasimhan, Sam (SD-EX)" <[email-masked]>
Date: Mon, 18 Sep 2000 23:27:58 -0400

Dear Jan and Kikuchi-San,

 I support Jan's proposal and I am sorry to see no
support for this from Kikuchi-San. MPEG will define a
format for carriage of MPEG-4 ES only which will require
CTS and DTS (like we did for MPEG-2 carriage) and this
will not be backward compatible with Kikuchi-San's draft.
If so, then one has to choose a more generic proposal.

Best Regards
Sam Narasimhan
Motorola

-----Original Message-----
From: Yoshihiro Kikuchi [mailto:[email-masked]]
Sent: Monday, September 18, 2000 3:39 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; Yoshihiro Kikuchi
Subject: Re: comments on in-band-signaling proposal

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

> 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]
> Dear Kikuchi-San and experts,
>
>    in the SL header and this will be in the adaptation field. In addition,
>  If your draft can accommodate this simple extension, then it will enable
>  Jan Vandermeer may also have some suggested changes to the draft, if this
> Best Regards
> Sam Narasimhan
> Motorola

---

From: Zvi Lifshitz <[email-masked]>
Date: Tue, 19 Sep 2000 09:31:19 +0200

[Reply:]

In Paris we said that in cases when DTS is not required (we never said it 
would always be required as you seem to propose) then it can be backward 
compatible.

z
Optibase Ltd.				GSM: +972-54-461787
> Come see us at:
The ISP Forum, Cavalieri Hilton, Rome, October 2nd-5th, 2000 
www.isp-conferences.com/ispf2000
Streaming Media Europe Earls Court Centre, Booth # 628, London, October 
10th-12th, 2000

---

From: "Luthra, Ajay (SD-EX)" <[email-masked]>
Date: Thu, 21 Sep 2000 13:16:31 -0400

Zvi,
  Assuming CTS=DTS is confusing. If you have B-frames then there can be a
large (arbitrary with no legal upper limit put by MPEG) difference between
CTS and DTS. All the profiles except Simple use B-frames. So, unless we are
defining this only for the carriage of MPEG4 Simple Profile ES over IP, this
assumption does not seem to make sense. Due to instantaneous decoding model
at the System Level, one can assume that the picture is instantaneously
decoded and available for the prediction of next frame at DTS time (if DTS
is present). However, this is not same as assuming CTS=DTS. Actually, if you
are sending only one Time Stamp then you send CTS and your assumption will
be DTS=CTS which will be a disaster. So, if there is no DTS and you have
B-frames then only reasonable choice is to not to assume it to be anything
(like DTS=CTS) and  hope / pray receiver decodes the picture as fast it can
and does not overflow. In MPEG-2 kind of environment with
fixed/limited/pre-defined frame rates, it was easier to live without paying
too much attention to DTS. I am not so sure about MPEG-4 where there is no
fixed frame rate. That is one of the reasons the buffer model is so messy in
the Video part of MPEG-4. Praying may not help here.

  Why is jitter forcing you to assume CTS=DTS? Are you saying that due to
jitter in IP networks B-frames are not allowed and we need only to use
Simple Profile? 

  Please clarify. Thanks.

With regards,
Ajay 

-----Original Message-----
From: Zvi Lifshitz [mailto:[email-masked]]
Sent: Friday, September 15, 2000 12:34 AM
To: 'Narasimhan, Sam (SD-EX)'; 'Yoshihiro Kikuchi'; IETF AVT;
[email-masked]'
Cc: Colin Perkins; [email-masked]'
Subject: RE: comments on in-band-signaling proposal

[Reply:]

The jitter on IP network is such that practically receivers may always
assume CTS=DTS for implementation of the buffer model.

Regards,

z
Send SMS from: 			http://isend.cellcom.co.il/English/Login.htm

---

From: Zvi Lifshitz <[email-masked]>
Date: Thu, 21 Sep 2000 20:59:48 +0200

Ajay,

You're right assuming DTS=CTS is not sufficient, but I believe we need to 
assume CTS-DTS < delta, when delta has an upper limit. If it doesn't we are 
in troubles because we don't know how much memory to allocate to the 
composition buffer. If indeed delta is known, it can be used to calculate 
the extra memory the decoding buffer would need to compensate for its 
ignorance of DTSs.

z

-----Original Message-----
From:	Luthra, Ajay (SD-EX) [SMTP:[email-masked]]
Sent:	Thursday, September 21, 2000 7:17 PM
To:	'Zvi Lifshitz'; 'Narasimhan, Sam (SD-EX)'; 'Yoshihiro Kikuchi'; IETF 
AVT; [email-masked]'
Cc:	Colin Perkins; [email-masked]'
Subject:	RE: comments on in-band-signaling proposal

Zvi,
defining this only for the carriage of MPEG4 Simple Profile ES over IP, 
is present). However, this is not same as assuming CTS=DTS. Actually, if 
you
fixed frame rate. That is one of the reasons the buffer model is so messy 
in

  Please clarify. Thanks.

With regards,
Ajay

-----Original Message-----
From: Zvi Lifshitz [mailto:[email-masked]]
Sent: Friday, September 15, 2000 12:34 AM
To: 'Narasimhan, Sam (SD-EX)'; 'Yoshihiro Kikuchi'; IETF AVT;

[Reply:]

Regards,

z

---

From: Zvi Lifshitz <[email-masked]>
Date: Thu, 21 Sep 2000 21:39:24 +0200

I think whatever delta an application assumes would be implemented by 
extending the terminal buffers accordingly. I still don't see how knowing 
the explicit DTS helps the terminal. Maybe I don't understand something, 
but thinking about it as a developer, I don't care whether the difficulties 
are on implementing the decoding buffer model, or accommodating DTS < CTS 
at the composition buffer.

z

-----Original Message-----
From:	Luthra, Ajay (SD-EX) [SMTP:[email-masked]]
Sent:	Thursday, September 21, 2000 8:31 PM
To:	'Zvi Lifshitz'; 'IETF AVT'
Cc:	[email-masked]'
Subject:	RE: comments on in-band-signaling proposal

But MPEG does not put any limit on that Delta (CTS-DTS). In MPEG-2,
different user groups (like ATSC, SMPTE, DVD, DVB etc) put their own 
 limits
for their own applications. It is not clear at this stage if those limits
will be carried in the Internet world or not. They may not, as many 
Internet
applications and users are lot more delay tolerant. So, if we have to 
assume
some Delta at this stage then I would say that the proposal is broken as
with in MPEG, currently, there is no assigned value to it, except in Simple
Profile. Am I missing something?

With regards,
Ajay

-----Original Message-----
From: Zvi Lifshitz [mailto:[email-masked]]
Sent: Thursday, September 21, 2000 12:00 PM
To: 'Luthra, Ajay (SD-EX)'; 'Narasimhan, Sam (SD-EX)'; 'Yoshihiro
Kikuchi'; IETF AVT; [email-masked]'
Cc: Colin Perkins; [email-masked]'
Subject: RE: comments on in-band-signaling proposal

Ajay,

z

-----Original Message-----
From:	Luthra, Ajay (SD-EX) [SMTP:[email-masked]]
Sent:	Thursday, September 21, 2000 7:17 PM
To:	'Zvi Lifshitz'; 'Narasimhan, Sam (SD-EX)'; 'Yoshihiro Kikuchi'; IETF

Zvi,

  Please clarify. Thanks.

With regards,
Ajay

-----Original Message-----
From: Zvi Lifshitz [mailto:[email-masked]]
Sent: Friday, September 15, 2000 12:34 AM
To: 'Narasimhan, Sam (SD-EX)'; 'Yoshihiro Kikuchi'; IETF AVT;

[Reply:]

Regards,

z