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

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

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,

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
soon the whole world will STREAM
==================================================================
Zvi Lifshitz				Phone +972(2)679-4788
[email-masked]			Fax +972(2)679-4789
Optibase Ltd.				GSM: +972(54)461-787
http://www.optibase.com		US voice mail/fax  +1(206) 888-4149
==================================================================
> 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

-----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,
  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

[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.

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: Stephan Wenger <[email-masked]>
Date: Fri, 22 Sep 2000 03:00:40 +0200

>Profile. Am I missing something?

My remark to that thread would be that it may be desirable that a payload spec
allows for the full functionality of a media coding, but that there is no 
obligation
to have such an attribute.

Maybe a sentence indicating that, when B-frames are used, it is necessarily
to carefully tune the size of the playout buffer may be enough?

I personally would object to add more timestamp fields in the payload header
just to accommodate some theoretically possible applications that are more
than unlikely to happen in the field.

Stephan