Opened 5 years ago

Closed 5 years ago

Last modified 4 years ago

#6432 closed defect (invalid)

~1800 DNS requests per hour

Reported by: Darkjacky Owned by:
Priority: normal Component: undetermined
Version: unspecified Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


Summary of the bug:
I am recording a stream and I found out through pi-hole logging that FFmpeg is doing ~1800 DNS requests every hour. Basically it looks like FFmpeg does not care about DNS TTL.
How to reproduce:

ffmpeg -i -bsf:a aac_adtstoasc -vcodec copy "/tmp/test.mp4"

Please let me know if you need more information.


Change History (6)

comment:1 by Steven Liu, 5 years ago

sysctl -a | grep ttl

or this maybe should fix by your system, not ffmpeg

comment:2 by Darkjacky, 5 years ago

#sysctl -a | grep ttl
net.ipv4.inet_peer_maxttl = 600
net.ipv4.inet_peer_minttl = 120
net.ipv4.ip_default_ttl = 64

The DNS requests go out every ~10 seconds. 4 each time.

comment:3 by Nicolas George, 5 years ago

This sysclt output means Linux. On Linux, like all real Unix, DNS resolving is done by the libc, not the kernel, so this sysctl output is completely useless ; the DNS TTL has nothing to do with the packets' TTL.

FFmpeg indeed does not care about DNS TTL. In fact, like all normal network applications for Unix, it does not even has access to it. If you want to reduce outgoing queries, you need to install a local cache, either nscd or a real DNS cache.

But remember that each DNS request will likely result in a network connection immediately afterward, so the benefit is limited.

comment:4 by Darkjacky, 5 years ago

Resolution: invalid
Status: newclosed

Alright in that case I will close this ticket.

Thanks for your help.

comment:5 by Carl Eugen Hoyos, 4 years ago

Component: ffmpegundetermined
Version: 3.2.4unspecified

comment:6 by gjdfgh, 4 years ago

Note that FFmpeg used to make create new TCP connections for each HLS segment. There is some new code in FFmpeg git master (I think it's even enabled by default) that will usually reuse the TCP connection, making the thing more efficient. Might be worth trying.

Note: See TracTickets for help on using tickets.