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

From: Franceschini Guido <[email-masked]>
Date: Mon, 09 Dec 2002 12:53:48 +0100

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

---

From: [email-masked]
Date: Wed, 11 Dec 2002 16:00:10 +0100

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

---

From: Franceschini Guido <[email-masked]>
Date: Wed, 11 Dec 2002 17:18:08 +0100

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

Sent by: 

2002-12-09 12:53 PM 

        Classification:         

Jan, all, 

  

  

Best regards 

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, 

Best regards,

Jan van der Meer

---

From: [email-masked]
Date: Thu, 12 Dec 2002 13:47:01 +0100

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

Sent by: 

2002-12-09 12:53 PM 

        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, 

  

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. 
  
duration must be known. This in general is not  possible unless parsing 
the config attribute for the media stream. This config  attribute is media 
  
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 

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]; 

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

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