有头条的数据没？

@tony1016 现在看起来就是 vaapi 硬件加速有问题。

@wangkun025 mpv 确实比 vlc 好很多，默认配置播放正常。

@zwy100e72

mpv -v xx.mkv 默认不指定解码器的时候，应该是使用的软解没问题。

```
[vd] Opening decoder hevc
[vd] No hardware decoding requested.
[vd] Using software decoding.
[vd] Detected 24 logical cores.
[vd] Requesting 16 threads for decoding.
[vd] Selected codec: hevc (HEVC (High Efficiency Video Coding))
```

mpv --hwdec=auto-copy xx.mkv 指定硬件解码的时候，还是有 vlc 一样的问题，色块。

```
Using hardware decoding (vaapi-copy)
```

可能安装 amf-amdgpu-pro 会有所改善

👍 太感谢了，解决了。

一般一个 feign client 就是一个 encoder / decoder 吧，什么场景下会需要灵活配置？

@chloerei 很有帮助

@fzinfz 是的，这个可以，综上所述，我觉得还是 openvpn 的桥接模式方便点，不需要一个个配置

@lry #25 说错了，应该叫路由转发。https://www.jianshu.com/p/3d5ada946a31

@cdlnls @XiaoxiaoPu
这个问题解决了。如果 openvpn 用的路由模式 (dev tun)，需要 win10 服务器上开启端口转发，并且在虚拟机里面添加一条静态路由（ route add -net 10.8.0.0/24 gw 192.168.204.1 ）
或者使用 openvpn 的桥接模式（ dev tap ），将 openvpn 的 Tap-Windows Adapter V9 虚拟网卡和 VMware 的 Vment8 NAT 虚拟网卡桥接下

@cdlnls @ourgoder 我这边客户机是 MacOS，主机是 Win10，虚拟机才是 Debian
贴了下客户机上面的路由，感觉这个路由没有问题 😂
https://paste.ubuntu.com/p/FxNdJV2n3X/

@XiaoxiaoPu
@cdlnls 我撤去了 OpenVPN,直接在客户机上面加了一条静态路由 `sudo route -n add -net 192.168.204.0 -netmask 255.255.255.0 192.168.0.108`，同时抓包服务器上的以太网卡和 Vmware 的 nat 网卡，发现客户机 telnet 虚拟机的 tcp 包第一次握手就收不到 ack，但是 虚拟机 telnet 客户机的包连接正常。这种一般会是什么问题

图 1: 192.168.0.107 --> 192.168.204.10
https://i.loli.net/2021/02/07/UrbXvO9En2764lH.png
图 2: 192.168.204.10 --> 192.168.0.107
https://i.loli.net/2021/02/07/zIPnVkiY2758THE.png

@XiaoxiaoPu 客户端可以直接连服务端没问题，但是服务端上的虚拟机用的 NAT 模式（装的时候未选择桥接模式），客户端和虚拟机不在同一个网段。

@UnknownSky 端口转发可以，但是这样就得为每一台虚拟机配置一个端口转发了，我觉得用 OpenVPN 也可以实现这个效果，而且不用记住虚拟机配置的端口转发，直接使用虚拟机 ip 。（谁要连主机上的虚拟机，就直接装个 OpenVPN 的客户端，但是我这配置好像有问题，连不上）

@UnknownSky 我的目的是让 NAT 后面的虚拟机暴漏出来，这样同局域网下的其他机器可以连上去。

@yfwl
@freecloud
国内的机器都不考虑 一是不方便 二是价钱太贵了 :)

莫名其妙 字幕组什么时候沦陷了？？？

@lry #52 来自微博用户 "Terence 说要有光"

@Terence 说要有光: 不合规的是小米的签名白名单机制，使得没有预装 GMS 的机型可以通过用户手动安装。这个机制是大约五年前引入的，谷歌在上个月发现并要求 90 天内整改否则披露。高端机上是本来就有预装，所以本来就合规。
---
这个解释明显比楼上那些说美国名单的靠谱