<div>Good day, Ross!</div><div><br></div><div>I mean the timestamps that I obtain in frame's callback, which is setup using MediaSink::fSource->getNextFrame(..., &on_frame, ...);<br></div><div><br></div><div>void on_frame(void* clientData, unsigned int frameSize, unsigned /*numTruncatedBytes*/, struct timeval tv, unsigned /*durationInMicroseconds*/)</div>
<div>{</div><div> // tv - is my timestamp</div><div>}</div><div><br></div><div>I didn't saw the packet loss in the openRTSP tool. As I said before, the problem is the same on both network protocols UDP and TCP, so I think its not a network issue.</div>
<div><br></div><div>My server is NVC1000 encoder by UDP Technology, here is detailed description <a href="http://www.udptechnology.com/products/IP/NVC1000.html">http://www.udptechnology.com/products/IP/NVC1000.html</a></div>
<div><br></div><div>There is no such problem in VLC player or NVC1000 SDK Tool while playing their stream (both uses live555 RTSP client) in the same environment. Also, the problem is independent of network environment: my customer viewed the stream being in the same private network with the encoder, and I view the stream over the Internet from another continent. In both cases the problem is the same - small gaps between audio frames.</div>
<div><br></div><div>I will be glad get any advices, suggestions or ideas.</div><div><br></div>2010/3/20 Ross Finlayson <span dir="ltr"><<a href="mailto:finlayson@live555.com">finlayson@live555.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm not really sure which side is responsible for the problem... More like that I need your advice what to do and investigate next.<br>
<br>
I use live555 to receive video and audio streams using RTSP client. The problem is: when I fill audio buffer with audio-frames according to their timestamps<br>
</blockquote>
<br></div>
I hope you mean "presentation times" rather than "timestamps". (You should not be dealing with RTP timestamps directly, but instead "presentation times", which are derived automatically from RTP timestamps.)<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
, I get a small gaps between frames in the buffer. That causes unacceptable artefacts while playing. From the other side, if I simply concatenate incoming audio-frames, I got clear audio without artefacts. The problem is protocol-independent, I can hear the same artefacts on both TCP and UDP protocols.<br>
</blockquote>
<br></div>
First, you should make absolutely sure that you're not seeing network packet loss. You can check this by running "openRTSP" with the "-Q" option. (A small amount of packet loss would explain the presentation time gaps, but might not be noticeable when you concatenate the frames that you end up receiving.)<br>
<br>
Second, you haven't said anything about your server. It is the server that determines the frames' presentation times. I hope you don't see this problem with presentation times when you use *our* server implementation (either "testOnDemandRTSPServer" or "live555MediaServer"). What server are you using?<br>
-- <br><font color="#888888">
<br>
Ross Finlayson<br>
Live Networks, Inc.<br>
<a href="http://www.live555.com/" target="_blank">http://www.live555.com/</a><br>
_______________________________________________<br>
live-devel mailing list<br>
<a href="mailto:live-devel@lists.live555.com" target="_blank">live-devel@lists.live555.com</a><br>
<a href="http://lists.live555.com/mailman/listinfo/live-devel" target="_blank">http://lists.live555.com/mailman/listinfo/live-devel</a><br>
</font></blockquote><br>