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. I had been running a tcpdump the entire time using Apple's recommended settings to capture a packet trace.
Here is a graph of all packets
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.
Here is a graph of bytes in flight:
You can see that the bytes in flight get disrupted. 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.
Using this blog post, I did an analysis of "Bad TCP" by looking at:
(tcp.analysis.flags && !tcp.analysis.window_update)
and found this:
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. However, when I look at the raw packet capture in Wireshark and filter by
(tcp.analysis.flags && !tcp.analysis.window_update), all I see during this time window is TCP Retransmission and TCP Dup ACK.
I also looked at
tcp.analysis.ack_rtt, on the assumption that if there was a connection issue the round-trip-time would perhaps increase. However, it seemed to follow a pattern identical to bytes in flight.
(apologies about the differences in the x axis; Wireshark crashes frequently when making these graphs).
Based on these graphs, does this indicate that the issue lies in the connection between my Desktop and cloud ingest node, or does this instead indicate that the issues is on the Desktop machine itself?
I still have the complete 600+ MB pcap file so I can readily extract or produce additional graphs as necessary.
Thanks everyone - I am going to rerun this test with a tcpdump on both ends, Desktop and Ingest node, and update with more details. FWIW, right now, it appears that the incident began when the Ingest node slashed the TCP Window Size from 4096 to 1383.