Subject: [AVT] RE: draft-ietf-avt-mpeg4-simple-05.txt

From: Franceschini Guido <[email-masked]>
Date: Thu, 12 Dec 2002 12:27:04 +0100

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

                                                                                                                                         
                                                     To:   Jan vanderMeer/EHV/CE/PHILIPS@EMEA3                                           
                                                     cc:   [email-masked]                                          
                                                      [email-masked]                                                                       
                                                      [email-masked]                                                                 
               Franceschini Guido                     [email-masked]                                                                     
               <Guido.Franceschini@TILAB.             Colin Perkins <[email-masked]>                                                        
               COM>                                   [email-masked]                                                     
                                                      [email-masked]                                                                
               Sent by:                               [email-masked]                                                          
               [email-masked]              (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS)                                         
                                                     Subject:    RE: [Isma-tech] isma-tc-all: Draft-ietf-avt-mpeg4-simple-05.txt         
               11/12/2002 17:18                                                                                                          
               Please respond to                     Classification:                                                                     
               Franceschini Guido                                                                                                        

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

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

====================================================================
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
====================================================================
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt