[Live-devel] H264 stream timestamps jumping backwards with proxy
Ross Finlayson
finlayson at live555.com
Wed Apr 27 23:36:43 PDT 2022
> On Apr 27, 2022, at 11:06 PM, Juho Ylikorpi <juho.ylikorpi at node.fi> wrote:
>
> Hi,
>
> There is 100 cameras and each has own proxy process delivering streams to multiple different clients.
>
> I know that processes don’t interact, but something is causing timestamps jump backwards when stream is flowing trough this setup.
Since the processes don’t interact, this is unlikely to have anything to do with our code. The only thing in common between the processes is the underlying OS (and network) - so if there’s a problem, then that’s where it will be.
You mentioned earlier that you were using RTP/RTCP-over-TCP to access your back-end clients. Do you really need to use TCP here? Using TCP is data inefficient (compared to normal RTP/RTCP-over-UDP), and it *will not* prevent data loss if the back-end cameras’ data rate exceeds the capacity of your network. If your streams’ data rate exceeds the capacity of your network, and you’re streaming over UDP, then the data loss you get is straightforward: Some RTP or RTCP packets get dropped. But if you’re streaming over TCP, then the data loss you get is much more insidious: Data loss will occur when the OS (at the sender's end) runs out of internal buffer space for implementing TCP sockets. Note that some camera’s firmware might not recover cleanly if it runs out of TCP buffer space while streaming RTP/RTCP-over-TCP; it might end up transmitting corrupted (truncated) RTP or RTCP packets.
So I’d start by *not* accessing your back-end cameras using RTP/RTCP-over-TCP. But apart from that suggestion, you’re on your own here. Sorry.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
More information about the live-devel
mailing list