* On Wed, Feb 16, 2011 at 11:40:33AM -0600, Ken Norton said:
> It is actually very accurate in the studio. The problem is that you
> are many miles and a number of hops away from the studio. In fact, the
> feed to the transmitter sites is a digital stream which is using some
> form of MPEG compression. Depending on the particular algorithm used
> in their feeds add about two seconds delay.
Hmm, yes, this is a significant problem ... *grmbl*
What you could do is manage the delay in such a way that the pips arrived
at the far end within the right timeframe ... well, would be nice. :)
Or just rely on everyone running NTP. ;)
> Yup. Digital is sooo much better than analog.
>
> ;)
>
> I had actually worked with that particular broadcast company when they
> were deploying the digital STL links and this was a major issue. The
> older MPEG technologies were actually much quicker and efficient, but
> as usual, they insisted on deploying "the best" which meant far more
> overhead and a deeper read-ahead buffer.
*grin* I work for a company that makes STL links (APT) and one of our
biggest issues is the latency over IP ... while fixed clock transfer
systems are a fucker at times, especially with 44.1kHz (damn you!), the
downsides of the IP rx latency buffer is often so significant that it makes
a duplex link less than ideal ...
> Now we're deploying IP-based streaming technologies over fiber and the
> delay is getting worse and worse.
Well, the one advantage of extra bandwidth is that you can move over to a
linear system. But reliable 2.304mbps (+ RTP overhead, + FEC, + everything
else), which would be nice ... hmm. Or y'know, just use EAPTx 24. ;)
p
--
_________________________________________________________________
Options: http://lists.thomasclausen.net/mailman/listinfo/olympus
Archives: http://lists.thomasclausen.net/mailman/private/olympus/
Themed Olympus Photo Exhibition: http://www.tope.nl/
|