StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>The fact that you're buffering shouldn't make any difference as long as your samples are time-stamped correctly. If you don't time-stamp samples (i.e. call <a href="http://msdn.microsoft.com/en-us/library/windows/desktop/dd407022%28v=vs.85%29.aspx" rel="nofollow">SetTime</a> with NULL as in</p> <pre><code>pSample->SetTime(NULL, NULL); </code></pre> <p>the samples will be rendered by the renderers as quick as possible. If you do set the time stamps, the renderers will render the frame accordingly (wrt. the current stream time). Perhaps your buffering is causing samples to arrive late? In any case, setting the time stamps to NULL is a good way to test whether all the media is received and is in order.</p> <p>So to answer your question, yes you do need to set time stamps on the samples: real-time doesn't mean you that you can remove the timestamps. Network jitter will cause the arrival times of samples to differ and the time stamps must be set correctly if you want to view the stream(s) correctly. You don't need to wait any time before passing the samples to FillBuffer, as long as the time stamp is set, the renderer will take care of playing back the samples correctly.</p> <p>My approach, which has been working fairly well, is as follows: In the RTSP source filter perform the required buffering. Then, once the buffer has been filled, calculate the offset that will be used for <em>each</em> sample. You need to take into account the RTP timestamp of the first RTCP-synchronized sample received (ts_0) and the DirectShow <a href="http://msdn.microsoft.com/en-us/library/windows/desktop/dd318892%28v=vs.85%29.aspx" rel="nofollow">StreamTime</a> (st_0) at that point in time where you start playing back the samples. By the time you start passing samples through the pipeline, the stream time will likely not be zero anymore....</p> <p>The DirectShow timestamp ts_new of each sample will then be calculated as the </p> <pre><code>ts_new_x = ts_x - ts_0 + st_0 + 50ms </code></pre> <p>The 50ms is useful to set the time stamp of the sample a little into the future. The reason for this is to avoid the samples arriving at the renderer late. The end time of the sample can be set as ts_new_x + 1. IIRC this gets ignored anyway, but don't quote me on that.</p> <p>I would recommend reading all the sections in <a href="http://msdn.microsoft.com/en-us/library/windows/desktop/dd407202%28v=vs.85%29.aspx" rel="nofollow">http://msdn.microsoft.com/en-us/library/windows/desktop/dd407202(v=vs.85).aspx</a> a couple of times if you haven't already. I found this to be extremely useful during the implementation. </p> <p>Also, feel free to have a look at the <a href="http://sourceforge.net/projects/videoprocessing/" rel="nofollow">open source version of an RTSP source filter</a> I wrote. It's main purpose was to highlight some aspects of writing a live RTSP DirectShow source filter and supports PCM, AMR and MP3. I did add some minor H.264 support for it, but never got round to completing that part (IIRC it was able to play the live555 sample video streams). </p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload