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

From: [email-masked]
Date: Mon, 11 Mar 2002 12:00:56 +0100

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
 
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: "Dorairaj V" <[email-masked]>
Date: Mon, 11 Mar 2002 16:45:38 +0530

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, 

  Regards, 

  Philippe Gentric
  Software Architect
  Philips MP4Net

                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 .