<p>You can do this with <a href="http://gstreamer.freedesktop.org/" rel="nofollow">GStreamer</a> and a plugin called <a href="http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-good-plugins/html/gst-plugins-good-plugins-rtpjitterbuffer.html" rel="nofollow">rtpjitterbuffer</a>. There is an example usage on the bottom of that page with the gst-launch tool to do a simple desktop playback of an rtp stream with network errors.</p>

<pre><code>gst-launch-1.0 rtspsrc location=rtsp://192.168.1.133:8554/mpeg1or2AudioVideoTest ! rtpjitterbuffer ! rtpmpvdepay ! mpeg2dec ! xvimagesink
</code></pre>

<p>You can customize this to your need and set specific timeouts and also make a new network stream instead of doing desktop playback. You can do pretty much anything with gstreamer, you just have to read a bit into it.</p>

<p>Regarding hardware I don't know of any that does this but I'd guess its pretty expensive like it usually is with very specialized hardware.</p>

CC BY-SA 3.0
2014-08-25T13:45:09.443Z
(I thought I had commented here but I don't see it. Apologies for any dupe). Thanks, that looks promising. We'll have a chance to test it in the week ahead.
Jim Mack
CC BY-SA 3.0
2014-12-15T04:05:14.920Z
You can also use my library @ https://net7mma.codeplex.com which is both faster and more efficient than gstreamer.
Jay
CC BY-SA 3.0
2014-08-24T17:58:24.137Z
2014-08-24T17:58:24.137Z
timonsku
<p>We'll be receiving a media stream that will suffer varying time shifts, and we need a solution that will clock the video+audio out at a predictable rate. We can time stamp the input stream (assume SMPTE LTC) to aid in identifying the amount of shift that has occurred.</p>

<p>This is basically what a TBC does, but these delays may be on the order of seconds, so the buffer would have to be quite large. Total delay through the system is not important, as long as the time jitter is ultimately removed.</p>

<p>EDIT: This could also be thought of as a rate corrector. The incoming video will have a long-term average frame rate of (say) 30fps, but the short-term rate could vary +/- 10% from that. The goal is to buffer enough video so that the output rate can be exactly 30 fps.</p>

<p>Something that worked with encoded (say MP4 over RTSP) video would be ideal, but if we need to work in baseband (SDI etc) that's acceptable.</p>

<p>Anyone know of such a device or system?</p>

CC BY-SA 3.0
2014-08-24T15:53:16.167Z
so essentially you want to go from vfr to cfr on the fly?
timonsku
CC BY-SA 3.0
2014-08-24T16:28:21.360Z
Not quite. The input stream is a constant frame rate, but the arrival times may vary because of the path it takes. Think of it as having jitter and drift. This device or software would simply delay some frames more than others. It's a FIFO with separate input and output clocks: the input is clocked by the arrival of new frames, the output is clocked at a fixed rate. The goal is to have a known delay between the original CFR stream and the output CFR stream, that absorbs any path jitter.
Jim Mack
<video><standards-converter>
Need a video/audio 'time base corrector' with a very large time buffer
Jim Mack
# Need a video/audio 'time base corrector' with a very large time buffer

(Asked by: username_0 on 2014-08-24)

We'll be receiving a media stream that will suffer varying time shifts, and we need a solution that will clock the video+audio out at a predictable rate. We can time stamp the input stream (assume SMPTE LTC) to aid in identifying the amount of shift that has occurred.

This is basically what a TBC does, but these delays may be on the order of seconds, so the buffer would have to be quite large. Total delay through the system is not important, as long as the time jitter is ultimately removed.

EDIT: This could also be thought of as a rate corrector. The incoming video will have a long-term average frame rate of (say) 30fps, but the short-term rate could vary +/- 10% from that. The goal is to buffer enough video so that the output rate can be exactly 30 fps.

Something that worked with encoded (say MP4 over RTSP) video would be ideal, but if we need to work in baseband (SDI etc) that's acceptable.

Anyone know of such a device or system?

**Tags:** video, standards-converter

> **Comments:**
> **username_1**: so essentially you want to go from vfr to cfr on the fly?  
> **username_0**: Not quite. The input stream is a constant frame rate, but the arrival times may vary because of the path it takes. Think of it as having jitter and drift. This device or software would simply delay some frames more than others. It's a FIFO with separate input and output clocks: the input is clocked by the arrival of new frames, the output is clocked at a fixed rate. The goal is to have a known delay between the original CFR stream and the output CFR stream, that absorbs any path jitter.  

---

## 1 answers

### Answer by username_1 on 2014-08-24. Score: 3 | Accepted answer

You can do this with GStreamer and a plugin called rtpjitterbuffer. There is an example usage on the bottom of that page with the gst-launch tool to do a simple desktop playback of an rtp stream with network errors.
gst-launch-1.0 rtspsrc location=rtsp://192.168.1.133:8554/mpeg1or2AudioVideoTest ! rtpjitterbuffer ! rtpmpvdepay ! mpeg2dec ! xvimagesink

You can customize this to your need and set specific timeouts and also make a new network stream instead of doing desktop playback. You can do pretty much anything with gstreamer, you just have to read a bit into it.
Regarding hardware I don't know of any that does this but I'd guess its pretty expensive like it usually is with very specialized hardware.

> **Comments:**
> **username_0**: (I thought I had commented here but I don't see it. Apologies for any dupe). Thanks, that looks promising. We'll have a chance to test it in the week ahead.  
> **username_2**: You can also use my library @ https://net7mma.codeplex.com which is both faster and more efficient than gstreamer.  

---

