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

From: [email-masked]
Date: Thu, 12 Dec 2002 16:51:40 +0100

I like this approach too:

1) dont change the AU index stuff
2) introduce *optional* constantDuration

regards,

Philippe Gentric
Software Architect
Philips MP4Net
[email-masked]
http://www.mpeg-4.philips.com

                                                                                                                                               
                                                           To:   Franceschini Guido <[email-masked]>                             
                                                            Jan vanderMeer/EHV/CE/PHILIPS@EMEA3                                                
                                                           cc:   [email-masked]                                          
                                                            [email-masked]                                                                       
               Dave Singer <[email-masked]>               [email-masked]                                                                 
                                                            [email-masked]                                                                     
               Sent by:                                     Colin Perkins <[email-masked]>                                                        
               [email-masked]             [email-masked]                                                     
               .edu                                         [email-masked]                                                                
                                                            [email-masked]                                                          
               12/12/2002 14:36                             (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS)                                         
                                                           Subject:    Re: isma-tc-all: RE: [AVT] RE: [Isma-tech]                              
                                                            isma-tc-all:Draft-ietf-avt-mpeg4-simple-05.txt                                     
                                                                                                                                               
                                                           Classification:                                                                     

Guido, all

I think we are mixing several things here.  I think it is probably safe to add a parameter, so that the AU duration is explicit rather than implicit.  I don't think we should be doing wholesale surgery on the AUIndex field at this stage.  The text
currently says that you do interleave based on timestamps;  adding the duration parameter makes the calculation easier.  Please remember that the isma 1.0 spec is frozen and uses the same format.  Adding MUSTs or changing MUSTs and SHOULDs should be
avoided if at all possible.

I understand the motivation to make AU duration explicit rather than implicit.  I don't understand the surgery on AUIndex.

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

--

David Singer
Apple Computer/QuickTime

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt