> On Aug 9, 2023, at 8:03 PM, Андрій Олексійович Радченко
> wrote:
>
> The problem isn't with the network, but with the likelihood that the client
> or even the network itself might glitch. Can we really expect a system that's
> working fine now to continue operating smoothly in the coming d
The problem isn't with the network, but with the likelihood that the client
or even the network itself might glitch. Can we really expect a system
that's working fine now to continue operating smoothly in the coming days?
And if such a glitch occurs, we get a closed stream instead of a recovery,
ev
> On Aug 9, 2023, at 6:14 PM, Андрій Олексійович Радченко
> wrote:
>
> Yes, but there is no answer why live555 has to close the stream when it can't
> send it over TCP.
The comments in the code for “sendDataOverTCP()” explain this very clearly:
// The blocking "send()" failed, or ti
Yes, but there is no answer why live555 has to close the stream when it
can't send it over TCP. Other servers, as I understand, don't do it. And
clients can recover from inconsistent data. So, maybe I misunderstood
something, but I see no reason for such behaviour. Can you please
explain it to me?
> On Aug 9, 2023, at 5:37 PM, Андрій Олексійович Радченко
> wrote:
>
> Hi. I use live555 to create server and client that stream and get video and
> audio respectively. I use RTP over TCP due to possible bad network. If use
> UDP instead of TCP then in some situations can't get I-frames of H
Hi. I use live555 to create server and client that stream and get video and
audio respectively. I use RTP over TCP due to possible bad network. If use
UDP instead of TCP then in some situations can't get I-frames of H264
stream and nothing is decoding, showing etc, I can't afford this in my
system.
