Investigating bigger spikes in multi-tiled playout latency #103

@rbouqueau assigning this to you primarily for discussion/insights.

In the (C#, Unity, VR2Gather) runs I am seeing occasional random spikes in playout latency of around 300ms.

This is a pipeline with 4 tiles at 2 qualities each (but no quality switching, so each tile receiver remains getting the same stream).

This is with sender and receiver running on Windows, lldash-relay running on Linux, on a "remote" network (I put "remote" between quotes,
because the three machines are actually on the same desk physically, but the connection between sender/receiver and relay goes through the firewall to the lldash-relay running on an external network port).

Here are two graphs of sample runs.

Run 1:

Run 2:

The spikes are at t=33 in run 1 and t=40 in run 2.

I investigated the raw timing statistics and in both cases one of my DASH receivers experienced a network latency that was 300ms larger than the normal network latency.

Google suggests that the minimum TCP RTO timeout on Windows is 300ms.

Could it be that what is happening here is a retransmission? How could I test that theory?

Edit: why was I thinking this is a retransmission? It is much more logical if it was a delay in the opening of the next segment... Is there some way I can detect at the higher (C#, Python) layer that we are at a segment boundary? Is this something that we could encode in the DashFrameMetaData?