However, it seemed to follow a pattern identical to bytes in flight. I also looked at _rtt, on the assumption that if there was a connection issue the round-trip-time would perhaps increase. However, when I look at the raw packet capture in Wireshark and filter by ( & !_update), all I see during this time window is TCP Retransmission and TCP Dup ACK.
This seems to indicate a spike in TCP errors, so perhaps this does indicate a connection problem between the Desktop PC and the cloud ingest node.
Using this blog post, I did an analysis of "Bad TCP" by looking at: I'm assuming that, if the ingestion node went offline somehow, the bytes in flight would be consistent, or even start to accumulate as it streamed more and more data and didn't get an ACK back. You can see that the bytes in flight get disrupted. I would like to try to establish if this disruption came because of a connectivity problem between my Desktop computer and the ingestion node in the cloud, or because my Desktop computer itself was glitching, defective, or underpowered somehow while capturing and encoding the video stream from the camera. I had been running a tcpdump the entire time using Apple's recommended settings to capture a packet trace.
I am attempting to diagnose a ~45 sec drop (to 0 Kbps) in the reported RTMP streaming bitrate in OBS while publishing a live stream.
0 kommentar(er)
