aboutsummaryrefslogtreecommitdiffstats
path: root/libavfilter/vf_framepack.c
diff options
context:
space:
mode:
authorMartin Storsjö <martin@martin.st>2018-08-10 10:25:59 +0300
committerMartin Storsjö <martin@martin.st>2018-08-31 12:26:51 +0300
commit9b4c3f5aadf54ffd2a6e15746b1fd736379883c4 (patch)
tree826c8a9c283c79a7e468a6bf59a491d2c4c10f05 /libavfilter/vf_framepack.c
parent69caad8959982580504643d36aef22528e4aa6ce (diff)
downloadffmpeg-9b4c3f5aadf54ffd2a6e15746b1fd736379883c4.tar.gz
network: Add RFC 8305 style "Happy Eyeballs"/"Fast Fallback" helper function
For cases with dual stack (IPv4 + IPv6) connectivity, but where one stack potentially is less reliable, strive to trying to connect over both protocols in parallel, using whichever address connected first. In cases with a hostname resolving to multiple IPv4 and IPv6 addresses, the current connection mechanism would try all addresses in the order returned by getaddrinfo (with all IPv6 addresses ordered before the IPv4 addresses normally). If connection attempts to the IPv6 addresses return quickly with an error, this was no problem, but if they were unsuccessful leading up to timeouts, the connection process would have to wait for timeouts on all IPv6 target addresses before attempting any IPv4 address. Similar to what RFC 8305 suggests, reorder the list of addresses to try connecting to, interleaving address families. After starting one connection attempt, start another one in parallel after a small delay (200 ms as suggested by the RFC). For cases with unreliable IPv6 but reliable IPv4, this should make connection attempts work as reliably as with plain IPv4, with only an extra 200 ms of connection delay. Signed-off-by: Martin Storsjö <martin@martin.st>
Diffstat (limited to 'libavfilter/vf_framepack.c')
0 files changed, 0 insertions, 0 deletions