Subject: RE: [AVT] RE: [Isma-tech] isma-tc-all:Draft-ietf-avt-mpeg4-simple-05.txt

From: [email-masked]
Date: Thu, 12 Dec 2002 14:28:23 +0100

Guido,

I retrieved your email after sending my own one. I think your second 
solution is preferable, if it is required that AU-index MUST be zero if 
the AU duration is constant (either explicit or explicit). However, I 
would like to make up my final mind when seeing the text.

Best regards,

Jan 

Franceschini Guido <[email-masked]>
Sent by: 
[email-masked]
2002-12-12 02:02 PM

        To:     Jan vanderMeer/EHV/CE/PHILIPS@EMEA3
        cc:     [email-masked]
[email-masked]
[email-masked]
[email-masked]
Colin Perkins <[email-masked]>
[email-masked]
[email-masked]
[email-masked]
        Subject:        RE: [AVT] RE: [Isma-tech] isma-tc-all:Draft-ietf-avt-mpeg4-simple-05.txt
        Classification: 

Jan,
 
I am observing troubles in my e-mail communications. Did you received my 
answer to Philippe ?
I think it contains the answer to your point below as well.
Please confirm, and let me know which of the two counterproposals that I 
made would you prefer, if any.
I would be happy to generate a new text consistent with that.
Just in case, here is the exchange between me and Philippe:
 
Philippe,
I understand your points. I think that my goals can be met as well with 
some additional change that I think accomodates your observations too. 
Here are my proposals to accomodate your points.
In the .05 the MUST in the sentence "Each AU-index field MUST be coded 
with the value zero." is not explained but after some thought I deduced 
that it exists because the receiver is supposed to understand by the 
continuos presence of AU-Index=0 that it has to determine the index of the 
first AU in a packet by means of the RTP time stamp instead of the 
AU-Index field. As I explained in my initial mail, I suspect that this 
mechanism is actually weird and unsafe.
In .05_guido I proposed the following text:
A receiver can determine the index of each AU by means of the values
contained in the AU-Index and AU-Index-delta fields. In case of
fixed time duration per Access Unit, the AU-Index is redundant with
respect to the RTP time stamp, provided that such fixed time
duration per Access Unit is known at the receiver. In such a case
the RTP time stamp usually
provides better robustness to large bursts of packet losses, and is
therefore to be preferred. A fixed duration SHOULD be signaled by
the MIME format parameter "ConstantDuration", see section 4.1.
When the MIME format parameter "ConstantDuration" is signaled, the
receiver SHOULD use the RTP time stamp to determine the index of the
first AU in the RTP packet, instead of the AU-Index field.
 
My goals would be met as well also by modifying the above para as follows:
 
A fixed time duration per Access Unit SHOULD be signaled either 
explicitely by
the MIME format parameter "ConstantDuration", see section 4.1, or 
implicitely by a mode definition.
When a fixed time duration per Access Unit is signaled, the
receiver SHOULD use the RTP time stamp to determine the index of the
first AU in the RTP packet, instead of the AU-Index field.
 
The above change would solve your concerns on the addition of 
"ConstantDuration" in the various modes, but would still not solve your 
issue on the "Each AU-index field MUST be coded with the value zero." 
sentence.
 
If you really really care about that sentence, well, the following text 
would tolerate it:
A fixed time duration per Access Unit MUST be signaled either explicitely 
by
the MIME format parameter "ConstantDuration", see section 4.1, or 
implicitely by a mode definition.
When a fixed time duration per Access Unit is signaled, the
receiver MUST use the RTP time stamp to determine the index of the
first AU in the RTP packet, instead of the AU-Index field.
 
The SHOULDs have become MUSTs. This way a receiver would have simple and 
strict rules to use either RTP time stamps or AU-Index.
Indeed:
- if we had the first SHOULD, it might happen that a server delivers 
constant frame rate streams without signaling it, and would then encode 
AU-Index=0. Receivers, being unaware of fixed time duration per AU, would 
use AU-Index instead of RTP timestamp, leading to a mistake.
- if we had the second SHOULD, it might happen that a receivers ignores 
the fixed time duration signaling and chooses to always use AU-Index and 
never RTP timestamps. Being AU-Index=0, it would then incorrectly 
determine the index of the first AU in a RTP packet.
Ciao
Guido
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, December 12, 2002 11:27 AM
To: Franceschini Guido
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: draft-ietf-avt-mpeg4-simple-05.txt
 
Guido,
You added the new "constantDuration" parameter and operated changes 
regarding the rules on AU-index.
I agree that: the constantDuration parameter is a good idea and the rules 
on AU-index being always zero were a bit weird
However these changes are not vital to the specification, specifically 
they do not fix anything broken.
Furtheremore I am concerned about the way you introduced these changes 
because
this draft is supposed to be it the ultinate final terminal review phase 
...
actually we (the authors) have been claiming it was stable for more than a 
year now.
Specifically my problem is that there are several changes in sentences 
involving capitalized MUST.
I spotted the following occurences:
in "3.3.5 Low bit-rate AAC" the sentence:
"Each AU-index field MUST be coded with the value zero." was removed.
and in "3.3.4 Variable bit-rate CELP" the sentence:
" In addition to the required MIME format parameters, the following
parameters MUST be present: SizeLength, IndexLength, and
IndexDeltaLength and ConstantDuration. "
did not originaly contain "ConstantDuration"
(this is one is a major conformance breaker)
Therefore I recommend that the change are re-formulated so that:
* backward compatibility is guaranteed
* the new MIME parameters ConstantDuration is optional
i.e. use SHOULD instead of MUST.

regards,
 
Philippe Gentric
Software Architect
Philips MP4Net
[email-masked]
http://www.mpeg-4.philips.com
 
Guido
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, December 12, 2002 1:47 PM
To: Franceschini Guido
Cc: [email-masked]; [email-masked]; [email-masked]; 
[email-masked]; Colin Perkins; [email-masked]; 
[email-masked]; [email-masked]
Subject: Re: [AVT] RE: [Isma-tech] isma-tc-all:Draft-ietf-avt-mpeg4-simple-05.txt

Guido, 

Thanks a lot. Adding your ConstantDuration parameter does not look very 
complicated, but why did you also change the coding of AU-index ? This 
creates an incompatibility with what we had before. Would it be OK to just 
add the parameter and some associated text ? If yes, could you please 
provide again a "minimum solution" along these lines ?

Best regards,

Jan 

Franceschini Guido <[email-masked]> 
Sent by: 
[email-masked] 
2002-12-11 05:18 PM 
        
        To:        Jan vanderMeer/EHV/CE/PHILIPS@EMEA3 
        cc:        [email-masked]
[email-masked]
[email-masked]
[email-masked]
Colin Perkins <[email-masked]>
[email-masked]
[email-masked]
[email-masked] 
        Subject:        [AVT] RE: [Isma-tech] isma-tc-all: 
Draft-ietf-avt-mpeg4-simple-05.txt 
        Classification:        Unclassified 

Jan,  all, 
  
done!  Using revision marks. I included as well fixes to editorial 
mistakes in 3.3.4,  3.3.5 and A.4.1 
  
Guido 
-----Original Message----- 
From: [email-masked]  [mailto:[email-masked]] 
Sent: Wednesday, December 11,  2002 4:00 PM 
To: Franceschini Guido 
Cc:  [email-masked]; [email-masked]; [email-masked]; 
[email-masked]; Colin Perkins; [email-masked]; 
[email-masked]; [email-masked] 
Subject: RE:  [Isma-tech] isma-tc-all:  Draft-ietf-avt-mpeg4-simple-05.txt 

Hello Guido, 

Thanks for your suggestion; it would be great if it would help to  improve 
the draft. However, we really would like to close the subject on short 
notice, and the problem with your proposal is that we have no clear 
picture  yet of its consequences. Would it be possible for you to modify 
the current  -.05 draft (using the change mark feature of Word) as 
required for your  modification. That would very much help us to review 
its acceptability.   Thanks on beforehand. 

Best  regards, 

Jan 

Franceschini  Guido <[email-masked]> 

Sent by: 
[email-masked] 

2002-12-09 12:53 PM 
Please respond to Franceschini Guido 
 
        To:         Jan  vanderMeer/EHV/CE/PHILIPS@EMEA3 
[email-masked] 
[email-masked] 
[email-masked] 
[email-masked] 
Colin  Perkins  <[email-masked]> 
[email-masked] 
[email-masked]   
        cc:          
         Subject:        RE: [Isma-tech]  isma-tc-all: 
Draft-ietf-avt-mpeg4-simple-05.txt 

         Classification:         

Jan, all, 
    
there is a portion in .04 and also .05  that I believe could be 
significantly improved with a simple addition.   
I understand that my proposal might be  considered as a technical change, 
thus disregard it if it really represents a  source (the only source) for 
yet an additional delay in the approval of this  draft. 
However, please consider  it if that is not the case. 
  
Basically, I  observe that: 
- the draft is  intended to be media agnostic, but in the end it is not 
completely  agnostic 
- there is an ugly and  potentially broken mechanism for determining the 
AUindex to be used for  de-interleaving 
- there is  unnecessary complexity in the AUindex syntax 
  
All such points have an easy solution: the addition of a 
"ConstantDuration" attribute. 
  
That's indeed my  proposal: have this additional attribute to specify the 
duration (using the TS  resolution) of a frame, in case of constant frame 
rate streams 
  
This proposal derives from the following  observations: 
- When  interleaving, the receiver is supposed to deinterleave based on 
the AU-Index  information associated to each individual AU 
- Such information is normally conveyed by means of AUIndex  field (first 
AU in a packet) and AUIndexDelta field (subsequent AUs in a  packet) 
- The draft states that  the AUIndex field shall be set to 0 in case of 
constant frame rate, without  justifying this rule. I think I have however 
identified the likely reason  behind this rule: 
-- In case of  burst packet losses, the length of the AUIndex field is 
critical. Thus, to  avoid incorrect identification of AUs at the receiver, 
the AUIndex field  should be long 
-- In case of  constant frame rate, the AUIndex can be deduced however 
also from the RTP  Timestamp, once the AU duration is known. By doing so, 
the problem of  incorrectly identifying AUs at a receiver is solved in 
practice even in case  of very large bursts of packet losses 
-- Therefore the draft indicates that in case of constant frame rate  the 
RTP Timestamp is to be used to determine the AU-Index of the first AU in a 
 packet, instead of the AUIndex field itself. It indicates so by 
specifying the  rule of setting AUIndex=0 in case of constant frame rate. 
Quite cryptic  though. 
  
The abobe has several implications:   
1) in order to determine the AU-Index  from the RTP Timestamp, the AU 
duration must be known. This in general is not  possible unless parsing 
the config attribute for the media stream. This config  attribute is media 
dependent, thus the implication is that the Payload Format  is not anymore 
codec agnostic. 
2) the rule by which the AU-Index for the first AU in the packet is to  be 
derived from the RTP Timestamp or from the AUIndex field itself is based 
on  the fact that all AUIndex fields are set to 0. But in order for a 
receiver to  check this, it should in principle process the entire stream 
first! Or at  least a reasonable portion of the stream, so as to make a 
reasonable  guess. 
3) we would have a field  (AUIndex) whose syntax differs depending on 
whether the frame rate is constant  or variable, but no explicit signaling 
of this property. 
  
My proposal of defining a "ConstantDuration" attribute would solve all 
these problems, and make the specification cleaner and more 
understandable. 
Indeed:   
1) in order to determine the AU-Index  from the RTP Timestamp, the AU 
duration must be known. This value would be  carried by the 
"ConstantDuration" attribute. 
2) the rule by which the AU-Index for the first AU in the  packet is to be 
derived from the RTP Timestamp or from the AUIndex field  itself would be: 
if the "ConstantDuration" attribute is present, receivers are  advised to 
use the RTP Timestamp instead of the AUIndex field, since it is  more 
robust to large bursts of packet losses; if the "ConstantDuration" 
attribute is not present, receivers shall use the AUIndex field.   
3) the AUIndex would not need two  different syntaxes. It could convey the 
AU-Index for the first AU in all  cases. A receiver is then simply advised 
to derive the actual AU-Index for the  first AU from the RTP Timestamp 
when the "ConstantDuration" attribute is  present (see sentence above), in 
order to be more robust to long bursts of  packet losses. 
    
Best regards 

Guido Franceschini<?xml:namespace  prefix = o ns = 
"urn:schemas-microsoft-com:office:office" /> 

TILAB - Multimedia Division 

Via G.Reiss Romoli 274 

I-10148 Torino, Italy 

tel + 39 011 228 6137 

fax + 39 011 228 6299 

-----Original Message----- 
From: [email-masked]  [mailto:[email-masked]] 
Sent: Sunday, December 08, 2002  11:02 PM 
To: [email-masked]; [email-masked];  [email-masked]; 
[email-masked]; Colin Perkins;  [email-masked]; 
[email-masked] 
Subject:  [Isma-tech] isma-tc-all:  Draft-ietf-avt-mpeg4-simple-05.txt 

Dear all, 

Please find attached  draft-ietf-avt-mpeg4-simple-05.txt. It will be 
uploaded shortly. I hope to  inform you about the differences with -.04 
and the pre-release of -.05  shortly. In summary, all Last Call comments 
as well as all issues discussed in  and after the IETF Atlanta meeting are 
incorporated. It will be discussed in  the MPEG meeting the coming week (I 
will arrive there Tuesday morning).  Shortly after this meeting I expect 
to publish -.06, which should be the final  version. 

Best regards, 

Jan van der Meer 

==================================================================== 
CONFIDENTIALITY  NOTICE 
This message and its attachments are addressed solely to the  persons 
above and may contain confidential information. If you have  received 
the message in error, be informed that any use of the content  hereof 
is prohibited. Please return it immediately to the sender and  delete 
the message. Should you have any questions, please contact us  by 
replying to [email-masked]. Thank  you 
==================================================================== 

==================================================================== 
CONFIDENTIALITY NOTICE 
This message and its attachments are addressed solely to the persons 
above and may contain confidential information. If you have received 
the message in error, be informed that any use of the content hereof 
is prohibited. Please return it immediately to the sender and delete 
the message. Should you have any questions, please contact us by 
replying to [email-masked]. Thank you 
==================================================================== 

[attachment "draft-ietf-avt-mpeg4-simple-05-guido.zip" deleted by Jan 
vanderMeer/EHV/CE/PHILIPS] 

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by
replying to [email-masked]. Thank you
====================================================================