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

From: [email-masked]
Date: Mon, 16 Dec 2002 14:13:40 +0100

Hello Guido,

I was confusing, as I forgot to mention the other point, which is that the 
concept of a "sample rate" is not common to all MPEG-4 audio streams, and 
therefore the audio sampling rate is not always suitable for use as the 
RTP time stamp clock. And there is more; an AAC frame does not always has 
1024 samples, but sometimes 960 samples. And comparable problems may exist 
for other audio stream types. In other words, a generic solution, in which 
the RTP parser does not need to look into the config information, is not 
easily achieved. I asked our audio experts to look further into this 
subject, so I hope to come back on this subject later today.

Best regards,

Jan 

Franceschini Guido <[email-masked]>
Sent by: 
[email-masked]
2002-12-13 04:13 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]
[email-masked]
[email-masked]
        Subject:        RE: [AVT] RE: [Isma-tech]isma-tc-all:Draft-ietf-avt-mpeg4-simple-05.txt
        Classification: 

Jan, all,
 
thanks for the feedback, although not as positive as I hoped. See my 
comments below
 
Ciao
Guido
Guido, 

Thanks again. We discussed your proposal and concluded that adopting the 
new parameter constantDuration is OK, but without introducing new 
normative requirements, so as to avoid legacy problems.
[Franceschini Guido] 
My main objective (that the receiver knows exactly whether RTP timestamps 
or AU-Index are to be used to determine the index of a first AU in a 
packet) is still met, and that's the most important result. 
My second objective, i.e. to make the spec fully codec agnostic and 
simplify implementations would not be achieved by your resolution.
That's a real pity.
 
That means that we cannot accept your suggestion that in the four (CELP / 
AAC) modes the sampling rate of the RTP time stamps MUST be set to the 
audio sampling rate when the constantDuration is not present.
[Franceschini Guido] 
This only applies to the AAC modes, since for AAC the duration of a frame 
depends on the sample rate.
For CELP instead the duration of a frame is 20ms, very simple.
This means that the legacy arguments apply to the AAC modes only, since 
for CELP no issue exists. And obviously are restricted to the case of 
interleaving. Was this reduced impact well understood when you took your 
resolution ?
 
I am wondering how many products are around that implement .05 and 
specifically manage the AAC modes with interleaving and all possible 
parameter combination.... In my ISMA plugfest experiments I have observed 
that:
- many implementations do not support interleaving;
- those that do, rely on the .04 "profile" MIME parameter, which 
disappeared in .05
- I have not personally made any deeper test varying AAC configurations 
(number of channels, sample frequency, RTP timestamp units ...): I cannot 
assert that implementations are buggy, but certainly my proposal would 
have simplified a lot implementor's life. And of course, my tests have 
been partial and I do not assert to have full visibility of everybody's 
products.
 
Frankly, I am confused by the fact that the removal of the "profile" 
parameter does not break implementations while the addition of a 
constraint (which applies to a strict subset of the cases already impacted 
by the "profile" parameter) does.
Thus, sorry if I repeat myself: was the impact of the legacy problems due 
to my proposal well understood when you took your resolution ?
 
With respect to your suggested text, I would like to make some small 
simplifications to stay as close as possible to the original text, but 
that should be an editorial issue only. I hope this resolution is 
acceptable to you. 

Best regards,

Jan 

Franceschini Guido <[email-masked]> 
Sent by: 
[email-masked] 
2002-12-12 03:23 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]
[email-masked] 
        Subject:        RE: [AVT] RE: 
[Isma-tech]isma-tc-all:Draft-ietf-avt-mpeg4-simple-05.txt 
        Classification:        Unclassified 

Jan, 
  
here  is .05_guido2, that hopefully meets your requests while still 
providing the  improvment I am asking for. 
  
Ciao 
Guido 
-----Original Message----- 
From: [email-masked]  [mailto:[email-masked]] 
Sent: Thursday, December 12,  2002 2:28 PM 
To: Franceschini Guido 
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 

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   

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