Subject: [AVT] comments on the rest of the document draft-ietf-avt-mpeg4-multisl-04.txt

From: "Dorairaj V" <[email-masked]>
Date: Thu, 7 Mar 2002 14:18:27 +0530

Hi Philippe ,
The following are my comments on the rest of the document draft-ietf-avt-mpeg4-multisl-04.txt  .

Thank you
Dorai

1)  Minor modification in example code provided in Section 6.1 . The example code to compute the CTS in single SL mode had a minor issue . The modified code is provided by me

if ( CTSDeltaLength == 0) { // or CTSDeltaLength is absent 
      // CTS is not transported for this RTP stream 
      if (i == 0){ // first SL packet in RTP packet 
         if ( SLConfig.useTimeStamps == 1 ) { 
            if ( SLPacketHeader.accessUnitStartFlag == 1 ) { 
               SLPacketHeader.compositionTimeStampFlag(0) = 1; 
               SLPacketHeader.compositionTimeStamp(0) =  
                   corrected(RTP TimeStamp); 
            } 
            else { 
               // ignore 
            } 
         } 
         else { 
             // empty 
         } 
      } 
      else { // non-first SL packets in RTP packet 

            if ( SLConfig.useTimeStamps == 1 ) { 
             if ( SLPacketHeader.accessUnitStartFlag == 1 ) { 
                SLPacketHeader.compositionTimeStampFlag(i) = 0; 
             } 
             else { 
                // ignore 
             } 
         } 
         else { 
             // empty 
         } 
      } 
   } 
   else { // CTSDeltaLength is not zero 
      // CTS is transported for this stream 
      if ( SLConfig.useTimeStamps == 1 ) { 
         if ( SLPacketHeader.accessUnitStartFlag == 1 ) { 
             SLPacketHeader.compositionTimeStampFlag(i) = 
                      PayloadHeader.CTSFlag(i); 
   // Modified by Dorai
    // In Single SL Mode , CTS Delta is not present

   if (!PayloadHeader.CTSFlag(i) {
    SLPacketHeader.CompositionTimeStamp(i) = corrected(RTP TimeStamp)
    }
   else {
    SLPacketHeader.compositionTimeStamp(i) =  
                corrected(RTP TimeStamp) + PayloadHeader.CTSDelta(i); 
   }
         } 
         else { 
            // ignore CTSFlag (which must be zero) 
         }
  
    else { 
         // this is strange and sub-optimal at best 
         // a receiver should ignore this 
    } 
   } 
  }

2) Appendix.2 . MPEG-4 Video with SL .

In the example of SLConfigDescriptor , timeStampResolution is given as 30 and OCRResolution is given as 0 .
Similarly in Appendix 6 , SL ConfigDescriptor  , timeStamp resolution is given as 0 and OCRResolution is given as 30 .

The issues here are 

a) It has to be made clear that OCRResolution and TimeStampResolution has to be same since OCRDelta is calculated from CTS  and CTS is expressed   in terms of TimeStampResolution . In MPEG-4 Systems these values are different since computation of OCR is independent of CTS .

b) In the example given 'vop_time_increment_resolution' or put in simple terms 'Frames Per Second' of video is used as TimeStampResolution . If  OCRResolution is made to be same as timeStampResolution and TimeStampResolution has a value say 5 , then the resolution of OCR automatically reduces  (This despite the fact we might have 32 bits allocated to OCR) . The problem becomes much more serious if say an AAC-LC bitstream at 44.1 Khz depends on video stream for its OCR (Using OCR_ESID  in  ES_Descriptor of MPEG-4 systems)  .

Hence instead of having media specific time stamp resolution  , it  might be useful to have a common time stamp resolution which suits the needs of all the media streams . 

These comments  can be provided in appendix .

**************************************************
Dorairaj V  
Senior Software Engineer
Terminal Devices Division
Sasken Communication Technologies
139/25 Amar Jyothi Layout
Ring Road
Domlur
Bangalore , India
email : [email-masked]
url   : www.sasken.com
phone
 off :+91 80 5355501 x 1191
 Res :+91 80 5618552

*************************************************

---

From: [email-masked]
Date: Mon, 11 Mar 2002 14:33:50 +0100

Dorai,

Sorry for being unvoluntarily cryptic (not enough coffee, too many typos)

 I will incorporate your remarks because they are completely right,

I.e. this example # 6 of the appendix requires the fix you indicate,
that time stamps must be based on the sampling clock: 44.1 KHz  and OCR 
too.

 I was waiting for possible comments on your comments but assume none will 
come by now.

By "editorial" I was trying to make a short cut to the idea that your 
comments
does not impact the specification itself, indeed in section 3.4.3 we 
already have
the sentence:

   "With this payload format OCRs MUST have the same clock frequency as 
   Time Stamps." 

**************************

I beleive it is natural to leave it to implementer to choose the best 
stream to carry OCR
in case of multiple streams ... I dont see however why the choice may be 
difficult, 
for example 44.1 KHz (audio) against 90 KHz (video),
I would choose to use the most accurate clock, i.e. the video one ?

(even then, for a lot of the reasons you would want to transport a clock
the audio sampling clock accuracy (even 8 kHz) is good enough ?
 ... so I dont want to mandate anything ?)

I cannot see any problem with that other than the practical implementation
issue that you have to be careful so that your computation at the receiver
does not propagate rounding errors i.e. you must keep the "master"
clock for the OCR as an integer  register counting ticks ?

******************************

Of course there is this limitation that the payload format cannot 
transport
(as they are) SL streams which dont have the same clock as the OCR they 
contain,
but this issue was discussed almost a year ago and found acceptable ...

am I missing something ?

Regards,

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

"Dorairaj V" <[email-masked]>
Sent by: [email-masked]
03/11/2002 12:15

        To:     Philippe Gentric/LIM/CE/PHILIPS@EMEA1
        cc:     <[email-masked]>
<[email-masked]>
        Subject:        Re: [AVT] comments on the rest of the document 
draft-ietf-avt-mpeg4-multisl-04.txt
        Classification: 

Hi Philippe ,
 Please excuse me , however I could not get the meaning of the sentence
"Since  they are editorial is nature and 
I am not expecting more comments about them now (anybody ?) " . 
 
With regards
Dorai

----- Original Message ----- 
From: [email-masked] 
To: Dorairaj V 
Cc: [email-masked] ; [email-masked] 
Sent: Monday, March 11, 2002 4:30 PM
Subject: Re: [AVT] comments on the rest of the document 
draft-ietf-avt-mpeg4-multisl-04.txt

Dorai, 

Thanks for these comments! 

Since  they are editorial is nature and 
I am not expecting more comments about them now (anybody ?) 
they will be incorporated ASAP (.i.e just after the Minneapolis meeting) 

Regards, 

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

"Dorairaj V" <[email-masked]> 
Sent by: [email-masked] 
03/07/2002 09:48 
        
        To:        Philippe Gentric/LIM/CE/PHILIPS@EMEA1
<[email-masked]> 
        cc:         
        Subject:        [AVT] comments on the rest of the document 
draft-ietf-avt-mpeg4-multisl-04.txt 
        Classification:         

Hi Philippe , 
The following are my comments on the rest of the document 
draft-ietf-avt-mpeg4-multisl-04.txt  . 
  
Thank you 
Dorai 
  
1)  Minor modification in example code provided in Section 6.1 . The 
example code to compute the CTS in single SL mode had a minor issue . The 
modified code is provided by me 

  
 
   else { 

  
  
In the example of SLConfigDescriptor , timeStampResolution is given as 30 
and OCRResolution is given as 0 . 
Similarly in Appendix 6 , SL ConfigDescriptor  , timeStamp resolution is 
given as 0 and OCRResolution is given as 30 . 
  
The issues here are 
  
a) It has to be made clear that OCRResolution and TimeStampResolution has 
to be same since OCRDelta is calculated from CTS  and CTS is expressed in 
terms of TimeStampResolution . In MPEG-4 Systems these values are 
different since computation of OCR is independent of CTS . 
  
b) In the example given 'vop_time_increment_resolution' or put in simple 
terms 'Frames Per Second' of video is used as TimeStampResolution . If 
OCRResolution is made to be same as timeStampResolution and 
TimeStampResolution has a value say 5 , then the resolution of OCR 
automatically reduces  (This despite the fact we might have 32 bits 
allocated to OCR) . The problem becomes much more serious if say an AAC-LC 
bitstream at 44.1 Khz depends on video stream for its OCR (Using OCR_ESID 
in  ES_Descriptor of MPEG-4 systems)  . 

Hence instead of having media specific time stamp resolution  , it  might 
be useful to have a common time stamp resolution which suits the needs of 
all the media streams .