ffmpeg -i input.mp4 -filter:v "minterpolate=mi_mode=2" output.mp4
предназначен для простой динамической быстрой интерполяции кадров с использованием небольшого размытия движения и вычислений.
192.168.1.19 не существует. 192.168.1.17 говорит вам, что его не существует. Поскольку он находится в той же подсети и является первым переходом, это предполагает, что 192.168.1.17, samsung.station, является системой, на которой вы запускаете traceroute и ping. Или 192.168.1.17 действует как прокси, и на него будут ссылаться любые неизвестные имена хостов. Другими словами, здесь не на что смотреть.
TL;DR:Проблема с сетью была вызвана ручным запуском dockerd
на WSL. Использование ip address
на одном терминале и tcpdump
обеспечивает большую ясность.
Детали
Все стало достаточно ясно, поэтому я делюсь своими действиями по устранению неполадок, если это того стоит. Принятый ответ абсолютно правильный, пинг шел с 192.168.1.17. У меня был открыт терминал Windows, и я думал об исходном IP-адресе на вкладке Powershell, хотя я запускал ping на вкладке Ubuntu WSL, так что это была моя ошибка. Если я сделаю ip a
на терминале WSL, я увижу интересную запись:
6: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:0b:14:ce:50 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.17/8 brd 192.255.255.255 scope global docker0
valid_lft forever preferred_lft forever
inet6 fe80::42:bff:fe14:ce50/64 scope link
valid_lft forever preferred_lft forever
Обратите внимание на тайну 192.168.1.17 . Я, наверное, видел это раньше, но проигнорировал, потому что интерфейс был отключен и весь шум от всех других интерфейсов. Действительно, у меня есть докер, установленный на WSL (с помощью apt, а не версии для Windows ), и я не уверен, как он взаимодействует с сетью, но, похоже, он дал очевидный прыжок. Что касается имени хоста, отображаемого рядом с точкой 17, я теперь видел разные имена, поэтому это явно какое-то кешированное имя, которое следует игнорировать, потому что оно вводит в заблуждение.
Легче увидеть операцию в файле PCAP в Wireshark, который я зафиксировал с помощью:
sudo tcpdump -i any icmp -w traceroute.pcap
Первый пакет:
1 0.000000 192.168.1.17 192.168.1.17 ICMP 104 Destination unreachable (Host unreachable)
И внутри ICMP:
Internet Control Message Protocol
Type: 3 (Destination unreachable)
Code: 1 (Host unreachable)
Checksum: 0x7313 [correct]
[Checksum Status: Good]
Unused: 00000000
Internet Protocol Version 4, Src: 192.168.1.17, Dst: 192.168.1.18
0100.... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
Total Length: 60
Identification: 0xa55a (42330)
Flags: 0x00
Fragment Offset: 0
Time to Live: 1
Protocol: UDP (17)
Header Checksum: 0x90e3 [validation disabled]
[Header checksum status: Unverified]
Source Address: 192.168.1.17
Destination Address: 192.168.1.18
User Datagram Protocol, Src Port: 36470, Dst Port: 33434
Таким образом, дополнительного прыжка нет. Я также заметил, что могу пропинговать цель с вкладки Powershell, но не с вкладки WSL. Поэтому я перезапустил WSL :
.> wsl --list -v
NAME STATE VERSION
* Ubuntu-20.04 Running 2
Debian Stopped 2
> wsl --shutdown Ubuntu-20.04
> wsl -d Ubuntu-20.04
Теперь, если я выполню ip a
во вновь запущенной оболочке WSL, последняя запись будет:
5: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
link/sit 0.0.0.0 brd 0.0.0.0
Интерфейс Docker исчез. Я снова могу выполнить ping из оболочки WSL. Затем меня осенило :Я запустил демон docker вручную с помощью sudo dockerd &
, и вот тогда связь оборвалась! Еще один интересный момент заключается в том, что виртуальная машина использует мостовой интерфейс, и хотя она имеет собственный IP-адрес и может пинговать все другие устройства в сети,он не может пропинговать IP-адрес хост-машины.
Хорошей новостью является то, что теперь у меня есть докер, работающий на виртуальной машине, и я могу подключиться к нему по SSH из WSL или, что еще лучше, прямо из PowerShell, и все работает нормально.