[Live-devel] How framerate is passing to rtsp client

Mon Apr 4 05:57:23 PDT 2016

Hi Ross,

1. I know that is difference between presentation time and timestamp. I 
will be typing more accurately next time.
2. My encoder generates NALs with synchronization four bytes included at 
the beginning.

My first NAL analyzed by bitstream analyzer.

/!! Found NAL at offset 4 (0x0004), size 18 (0x0012)
XX *00 00 00 01* 67 42 80 1E 95 A0 50 7C 84 00 00 0F

==================== NAL ====================
  forbidden_zero_bit : 0
  nal_ref_idc : 3
  nal_unit_type : 7 ( Sequence parameter set )
======= SPS =======
  profile_idc : 66
  constraint_set0_flag : 1
.
.
.

/It is not discrete NAL unit.

3. My implementation is based on testOnDemandRTSPServer. I added my 
subclasses according to advices founded here:
http://www.live555.com/liveMedia/faq.html#liveInput-unicast

I created my class H264VideoMemBuffServerMediaSubsession that inherits 
from H264VideoFileServerMediaSubsession

/FramedSource* 
H264VideoMemBuffServerMediaSubsession::createNewStreamSource(unsigned 
/*clientSessionId*/, unsigned& estBitrate) {
     estBitrate = 750;

     DeviceParameters params;
     DeviceSource* fileSource = DeviceSource::createNew(envir(), params);
     if (fileSource == NULL) return NULL;

     return H264VideoStreamFramer::createNew(envir(), fileSource);
   }/

My changes in ./testOnDemadnRTSPServer.cpp
was:
/sms->addSubsession(H264VideoFileServerMediaSubsession::createNew(*env, 
inputFileName, reuseFirstSource));/
I changed to:
/sms->addSubsession(//H264VideoMemBuffServerMediaSubsession//::createNew(*env, 
inputFileName, reuseFirstSource));/

My DeviceSource.cpp implementation:

void DeviceSource::doGetNextFrame() {
*  // usleep(110000); //live camera simulation*
     deliverFrame();
}

void DeviceSource::deliverFrame() {
   if (!isCurrentlyAwaitingData()) return;

// Updating pointer to new data and updating its size.
    // newFrameSize =
   //  newFrameDataStart =

   if (newFrameSize > fMaxSize) {
     fFrameSize = fMaxSize;
     fNumTruncatedBytes = newFrameSize - fMaxSize;
   } else {
     fFrameSize = newFrameSize;
   }

   gettimeofday(&fPresentationTime, NULL); // If you have a more 
accurate time - e.g., from an encoder - then use that instead.

      printf("Sending %u bytes", fFrameSize);
      if( fNumTruncatedBytes )
          printf(" with truncated %u bytes", fNumTruncatedBytes);
      printf("\tPresentation time: %u.%06u\n", 
(int)fPresentationTime.tv_sec, (unsigned)fPresentationTime.tv_usec );

   memmove(fTo, newFrameDataStart, fFrameSize);
   FramedSource::afterGetting(this);
}

4. I did one test. I had gathered in memory buffer more NAL units ( 
about 100 ). I was passing them without any delays. I have received 25 
fps in my video player and testRTSPClient was printing presentation time 
correlated with real time. There was not big difference between 
presentation time on printed on server and on client.
I next test I have added  one line to doGetNextFrame function:
usleep(110000);
This line simulated waiting time on next frame in live camera. In this 
case, problem with presentation time was appeared again.

START: Wall clock: 14:24:00
     Server:
         Sending 2993 bytes      Presentation time: 1459773496.311242
Client:
         Received 2989 bytes.    Presentation time: 1459773496.411603

Presentation time difference at the beginning of the transmission:*~100ms*

STOP: Wall clock: 14:25:40, 100 seconds elapsed:
     Server:
         Sending 10577 bytes     Presentation time: 1459773595.847020
     Client:
         Received 10573 bytes.   Presentation time: 1459773532.290209

Presentation time difference at the end of the transmission: *~63 seconds

*5. You asked about truncation. Sometimes fMaxSize in DeviceSource is 
too small and I must truncate data. I cant pass more than fMaxSize. It's 
not up to me.

Thanks for any hint.

Paweł
*
*
On 01/04/16 17:55, Ross Finlayson wrote:
>> I have compared logs from my rtsp server ( runned on embedded device) and rtsp client ( runned on PC) and I found difference in timestamps.
> You mean “presentation time”, not “timestamp”.  (Once again, you do not need to concern yourself with RTP timestamps - at all.  Please don’t mention them again; that inevitably turns the discussion into a ‘rat hole’, and wastes my time.)
>
>
>> On the server has elapsed 4.7 s
> During which time you transmit 46 NAL units.  Which implies a frame rate of (46-1)/4.7 =~ 9.5 frames per second.  That seems about right.
>
>> On the testRTSPClient has elapsed 1.6 s.
> More accurately, the computed *presentation times” span 1.6s.  (I’m sure that the actual elapsed time is about 4.7s)
>
> These symptoms suggest that your server is not computing presentation times properly.
>
> But you haven’t said anything about specifically how you generate H.264 NAL units, and feed them to your “H264VideoRTPSink”.  I suspect that this is your real problem.
>
> If you are generating ‘discrete’ H.264 NAL units - i.e., one at a time - then you must feed them into a “H264VideoStreamDiscreteFramer”, NOT a “H264VideoStreamFramer”.  Also, the H.264 NAL units that you feed into a “H264VideoStreamDiscreteFramer” MUST NOT begin with a 4-byte 0x00 0x00 0x00 0x01 ‘start code’.
>
> (You use a “H264VideoStreamFramer” only if your video comes from an unstructured H.264 byte stream - e.g., from a file.  It parses the byte stream and computes its own “fPresentationTime” and “fDurationInMicroseconds”.  Therefore, it’s not what you want.)
>
> Please send us your implementation of the “createNewStreamSource()” and “createNewRTPSink” virtual functions.  This may tell us what’s wrong.
>
> Also:
>> PIPE:LOS: Sending 4137 bytes with truncated 7685 bytes  Presentation time: 567993728.084010
> What is this ‘truncation’?  This is something that you will need to fix.  Your “H264VideoStreamDiscreteFramer” object must be fed a complete, untruncated H.264 NAL unit.
>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel

-- 
Paweł Domagalski
Software Engineer
Mobica Ltd.
www.mobica.com

Mobica is a provider of innovative, cutting-edge software engineering, testing and consultancy services. Based in the UK, Poland, the USA and Mexico, Mobica has a worldwide customer base and a proven track record in delivering complex solutions to global leaders in a range of sectors including automotive, mobile, semiconductor, finance, TV & broadcasting, telecommunications, connected devices, marine and aviation.

Mobica Limited is a limited company registered in England and Wales with registered number 05169596 and VAT registered number 845117630. Our registered office is at Crown House, Manchester Road, Wilmslow, Cheshire, SK9 1BH, UK.

This message is intended solely for the addressee(s) and may contain confidential information. If you have received this message in error, please send it back to us, and immediately and permanently delete it. Do not use, copy or disclose the information contained in this message or in any attachment.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20160404/3b17d6fe/attachment.html>