<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hi Ross,<br>
    <br>
    1. I know that is difference between presentation time and
    timestamp. I will be typing more accurately next time.<br>
    2. My encoder generates NALs with synchronization four bytes
    included at the beginning.<br>
    <br>
    My first NAL analyzed by bitstream analyzer.<br>
    <br>
    <i><small><small>!! Found NAL at offset 4 (0x0004), size 18 (0x0012)
          <br>
          XX <b>00 00 00 01</b> 67 42 80 1E 95 A0 50 7C 84 00 00 0F <br>
          <br>
          ==================== NAL ====================<br>
           forbidden_zero_bit : 0 <br>
           nal_ref_idc : 3 <br>
           nal_unit_type : 7 ( Sequence parameter set ) <br>
          ======= SPS =======<br>
           profile_idc : 66 <br>
           constraint_set0_flag : 1 <br>
          .<br>
          .<br>
          .<br>
          <br>
        </small></small></i>It is not discrete NAL unit.<br>
    <br>
    3. My implementation is based on testOnDemandRTSPServer. I added my
    subclasses according to advices founded here:<br>
    <a class="moz-txt-link-freetext" href="http://www.live555.com/liveMedia/faq.html#liveInput-unicast">http://www.live555.com/liveMedia/faq.html#liveInput-unicast</a><br>
    <br>
    I created my class H264VideoMemBuffServerMediaSubsession that
    inherits from H264VideoFileServerMediaSubsession<br>
    <br>
    <i><small>FramedSource*
        H264VideoMemBuffServerMediaSubsession::createNewStreamSource(unsigned
        /*clientSessionId*/, unsigned& estBitrate) {<br>
            estBitrate = 750;<br>
        <br>
            DeviceParameters params;<br>
            DeviceSource* fileSource = DeviceSource::createNew(envir(),
        params);<br>
            if (fileSource == NULL) return NULL;<br>
        <br>
            return H264VideoStreamFramer::createNew(envir(),
        fileSource);<br>
          }</small></i><br>
    <br>
    My changes in ./testOnDemadnRTSPServer.cpp<br>
    was:<br>
       <i><small>
        sms->addSubsession(H264VideoFileServerMediaSubsession::createNew(*env,
        inputFileName, reuseFirstSource));</small></i><br>
    I changed to:<br>
        <small><i>sms->addSubsession(</i><i><font color="#ff0000">H264VideoMemBuffServerMediaSubsession</font></i><i>::createNew(*env,
        inputFileName, reuseFirstSource));</i></small><br>
    <br>
    My DeviceSource.cpp implementation:<br>
    <small><small><br>
        void DeviceSource::doGetNextFrame() {<br>
         <b>  // usleep(110000); //live camera simulation</b><br>
            deliverFrame();<br>
        }<br>
        <br>
        void DeviceSource::deliverFrame() {<br>
          if (!isCurrentlyAwaitingData()) return;<br>
        <br>
        // Updating pointer to new data and updating its size.<br>
           // newFrameSize = <br>
          //  newFrameDataStart = <br>
        <br>
        <br>
        <br>
          if (newFrameSize > fMaxSize) {<br>
            fFrameSize = fMaxSize;<br>
            fNumTruncatedBytes = newFrameSize - fMaxSize;<br>
          } else {<br>
            fFrameSize = newFrameSize;<br>
          }<br>
        <br>
          gettimeofday(&fPresentationTime, NULL); // If you have a
        more accurate time - e.g., from an encoder - then use that
        instead.<br>
        <br>
             printf("Sending %u bytes", fFrameSize);<br>
             if( fNumTruncatedBytes )<br>
                 printf(" with truncated %u bytes", fNumTruncatedBytes);<br>
             printf("\tPresentation time: %u.%06u\n",
        (int)fPresentationTime.tv_sec,
        (unsigned)fPresentationTime.tv_usec );<br>
        <br>
          memmove(fTo, newFrameDataStart, fFrameSize);<br>
          FramedSource::afterGetting(this);<br>
        }<br>
        <br>
        <br>
        <br>
        <br>
        <big><big>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.<br>
            I next test I have added  one line </big></big></small></small><small><small><big><big>to
            doGetNextFrame function:</big></big></small></small><br>
    <small><small>usleep(110000);<br>
        <big><big>This line simulated waiting time on next frame in live
            camera. In this case, problem with presentation time was
            appeared again.<br>
            <br>
            START: Wall clock: 14:24:00<br>
                Server: <br>
                    Sending 2993 bytes      Presentation time:
            1459773496.311242<br>
          </big></big></small></small><small><small><big><big><small><small><big><big>   
                    Client:<br>
                            Received 2989 bytes.    Presentation time:
                    1459773496.411603<br>
                    <br>
                    Presentation time difference at the beginning of the
                    transmission:<b> ~100ms</b><br>
                    <br>
                    STOP: Wall clock: 14:25:40, 100 seconds elapsed:<br>
                        Server:<br>
                            Sending 10577 bytes     Presentation time:
                    1459773595.847020<br>
                        Client:<br>
                            Received 10573 bytes.   Presentation time:
                    1459773532.290209<br>
                  </big></big></small></small></big></big></small></small><small><small><big><big><small><small><big><big><small><small><big><big><small><small><big><big><br>
                                    Presentation time difference at the
                                    end of the transmission: <b>~63
                                      seconds <br>
                                      <br>
                                    </b>5. You asked about truncation.
                                    Sometimes fMaxSize in DeviceSource
                                    is too small and I must truncate
                                    data. </big></big></small></small></big></big></small></small></big></big></small></small></big></big></small></small><small><small><big><big><small><small><big><big><small><small><big><big><small><small><big><big><small><small><big><big><small><small><big><big><small><small><big><big><small><small><big><big>
                                                          I cant pass
                                                          more than
                                                          fMaxSize.</big></big></small></small></big></big></small></small></big></big></small></small></big></big></small></small>
                                    It's not up to me.<br>
                                    <br>
                                    Thanks for any hint.<br>
                                    <br>
                                    Paweł<br>
                                    <b><br>
                                    </b></big></big></small></small></big></big></small></small></big></big></small></small><big></big></big></big></small></small><br>
    <div class="moz-cite-prefix">On 01/04/16 17:55, Ross Finlayson
      wrote:<br>
    </div>
    <blockquote
      cite="mid:31782618-E8E4-4D96-B005-EA1307AD634F@live555.com"
      type="cite">
      <blockquote type="cite">
        <pre wrap="">I have compared logs from my rtsp server ( runned on embedded device) and rtsp client ( runned on PC) and I found difference in timestamps.
</pre>
      </blockquote>
      <pre wrap="">
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.)


</pre>
      <blockquote type="cite">
        <pre wrap="">On the server has elapsed 4.7 s
</pre>
      </blockquote>
      <pre wrap="">
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.

</pre>
      <blockquote type="cite">
        <pre wrap="">On the testRTSPClient has elapsed 1.6 s.
</pre>
      </blockquote>
      <pre wrap="">
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:
</pre>
      <blockquote type="cite">
        <pre wrap="">PIPE:LOS: Sending 4137 bytes with truncated 7685 bytes  Presentation time: 567993728.084010
</pre>
      </blockquote>
      <pre wrap="">
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.
<a class="moz-txt-link-freetext" href="http://www.live555.com/">http://www.live555.com/</a>


_______________________________________________
live-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:live-devel@lists.live555.com">live-devel@lists.live555.com</a>
<a class="moz-txt-link-freetext" href="http://lists.live555.com/mailman/listinfo/live-devel">http://lists.live555.com/mailman/listinfo/live-devel</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Paweł Domagalski
Software Engineer
Mobica Ltd.
<a class="moz-txt-link-abbreviated" href="http://www.mobica.com">www.mobica.com</a>

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.</pre>
  </body>
</html>