A strange TCP timestamp problem?
Dave Huang <khym <at> azeotrope.org>
2015-06-05 21:34:16 GMT
I wanted to record a video stream (HTTP Live Streaming) with ffmpeg,
but was getting errors like "Failed to open segment of playlist 0" and
"Connection timed out". However, I didn't have any problems watching
the video the regular way through a web browser on Windows (on the
same local network as the NetBSD machine running ffmpeg), so it didn't
seem like it was a network issue.
I tried a few more experiments and found that ffmpeg on Windows worked
fine, as did ffmpeg on Linux (Debian jessie), so it didn't seem like
an ffmpeg issue either (ffmpeg 2.6.3 in the case of NetBSD and Linux,
and on Windows, a git snapshot from 20141205).
This seemed to narrow the issue down to NetBSD. I collected some
tcpdump logs, and the problem seems to be that the remote server
doesn't always respond to NetBSD's TCP SYN packets. It almost seems
like the other end is doing some sort of rate limiting, since the
initial connection generally works (in the case of HTTP Live
Streaming, the one to download the playlist file), and the next one
works most of the time (downloading the first video segment), but the
connection to download the second segment of the video takes 3 SYNs to
get a response. Actually, ffmpeg times out before it connects, since
it expects to be able to download a new video segment every 5 seconds
or so, but I increased the timeout to see what would happen. But if I
wait a few dozen seconds and try again, the connection succeeds
immediately. In any case, it doesn't make sense for the remote end to
rate limit connections so aggressively, since the whole point of HLS
is that the client continually requests small chunks of video--but it
feels like that's what it's doing.
Looking at the tcpdump from Linux and Windows shows that all SYNs are