@SourceMan 大佬手下留情

這麼解釋就有可能了, 回過不少貼子, 不少都沒有推高, 我就感到奇怪......

用 VSCode 的原因是工作需要, 一時用 Windows 一時用 Mac, 還有時候要用 Ubuntu, 所以就統一用 VSCode 了 https://ws1.sinaimg.cn/large/b64a58e3gy1fikro1qf4lj200k00k3y9.jpg

@XinLake

我只是好奇, 一個調用 LibVLC 硬解的 app, 和一般能播 4K 格式的 video app, 一樣調用 MediaCodec 而特到硬解以達到省電效果, 為什麼可以說成是「专业的 APP 不耗电」......如果冒犯到了你就不好意思了, 繁體中文是我的母語, 可以最準確表達我的意思, 而你用簡體是你的自由也是這裡的通用語言, 大家看得懂就行。

I am just nobody, 我公開的經驗不多, 只有幾年前發在 hkepc 的文章被人抄到 xda-developers 上的紀錄
https://forum.xda-developers.com/showthread.php?t=2517925


我說的 OpenCV 抄 Demo 不是你, 而是一個來面試的, 我自己也在 Android 用過 OpenCV library 實現即時的 Camera 影像分析(遊戲玩法需求), 加上那面試者完全答不上顯示的 demo 的意義在那裡, 正在運算的是甚麼, 我才指出那人是拿著 demo 就說自己懂 OpenCV 的。

Google "LibVLC MediaCodec"第二個搜尋結果就找到了 LibVLC 用 MediaCodec 了......
modules/codec/omxil/mediacodec.h
還有看看 mediacodec_jni.c , 如果你質疑的話, 先看看自己用的 library 裡面有甚麼吧。


LibVLC 好處是包含大量現成的 demuxer, decoders(software 及 MediaCodec 硬解的都有)甚至連 Video/Audio 的輸出介面都很方面的接上, 在 Android 2.2 的年代我用過它來解決當年 Android 不能播 HLS 廣播的問題, 那個年代沒有 MediaCodec, 也沒有好用的 HLS + MPEG-TS java demuxer, ffmpeg wrapper 是可以解碼但要接 video/audio output 比較麻煩, 而 LibVLC 相對是一個能快捷調用的 turnkey 方案, 但弱點是能讓你用 Java 調用的地方不夠。

但是到了現代如果一個簡單的 Player app, 特別 4K 來說格式不多, Video codec 不外乎是 AVC/HEVC, 消費級的終端勉強可以說 10bit 分支也是不同的格式, 而 mp4 encapsulation 幾乎是標配, LibVLC 在我看來是老方案, 在我提出其他方案前, 可以說一下為甚麼要挑 LibVLC 嗎?

之前看到過，想不到是 IPv6 出口率先響應一帶一路

https://www.v2ex.com/t/418470

ChinaNet 歐洲方向比美國好一點，而且也有 Public peering，終於前進了一步

還好有移動競爭, 20Mbps 上行起碼可以 1080p 直播遊戲......

生產環境開 +1

因為伺服器是向全世界的用戶服務的, 不單面對國內, 跨洲 Internet 在高 latency 下的提升效果明顯, 速度是重要的。而且沒影響內網(一直有監測 latency 及 throughput)。對於不用面向客戶端的運維人員, 開 BBR 也是要額外工作吧, 反正自己用不著。

說內網開會浪費資源的, 純粹是對 BBR 不了解, 它畢竟是進入了 Linux kernel 的 Fair Congestion control, 不是像 KCP 一類的的進取兼不公平的搶佔。

而且最後一哩和國內骨幹網的質量完全不是可以比較的, 單是在商廈一類 WiFi 干擾嚴重的場境下, packet loss 情況影響更大, 這時 BBR 才會見到有效。我個人很喜歡用有線網絡, 但也很清楚一般用戶是以 WiFi 為主的。


@Love4Taylor 不影響的, NAT 的動作只是修一下 packet 的 address field, 不管 Congestion control

@237176253 3ms 那種港深專線, 不用佔用 Internet 容量的, 放心吧......世界加錢可及

FFMpeg 對 seeking 準確度的解說

https://trac.ffmpeg.org/wiki/Seeking
As of FFmpeg 2.1, when transcoding with ffmpeg (i.e. not just stream copying), -ss is now also "frame-accurate" even when used as an input option. Previous behavior (seeking only to the nearest preceding keyframe, even if not precisely accurate) can be restored with the -noaccurate_seek option.

要精確的話必需要重編碼沒錯, 但切片的動作可以分成這樣

第一輪先切成 raw video+raw audio 減少損耗, 精準 seeking 的話(-ss 放-i 前)就不會卡
然後第二輪用 concat 重編

我用 ffmpeg 來生成分段預覽, 因為不要求 frame-accurate, 就用 fast seeking(-ss 放-i 後)先以(T+K)切一段出來, T 是𢬒定時間, K 是 keyframe 時間, 第一輪先快速切片, 在第二輪壓制前把每個分片開始的 K 長度剪走, 這就能解決卡頓問題

LibVLC 也是用的 Android MediaCodec API, 說白了就只是個 wrapper 還要經 JNI 繞路到 MediaCodec, 而且不知道跟 CV 有甚麼關係, 就 framebuffer 可以接上而已。

這種接 open source libraries 的技能是有用沒錯, 但....你這種 demo 令我想起一個來見工的, 滿手好看的 demo, 但 OpenCV 就只是抄 demo 畫了一些標點出來, 問到該算法的特點也不上來, 卻說成自己發現似的。

@wangxiyi077 你的解讀是正確的, 不說 DWDM 是因為整段光纜中的分配情況不好說, 反正出口頻寬是按端口計算的

信道 是我國 《计算机信息网络国际联网出入口信道管理办法》的用詞, 但我的說法應該是改成「端口」比較好

Ubnt Inwall 系列 +1
正在用, 三個 GbE 口超級好用, 還有 PoE In/Out 可以廷接到下一個 AP, 裝修時可以少煩心 switch 放哪裡
規劃也容易, 直接讓師傳用多裝一組電線的工法就可以做到多點 AP 用網線相連

@237176253 才不會炸掉, 那點流量......

就當有一天 163 ChinaNet 突然改死性在 HKIX 弄 Public peering 好了。

總出口只有 3.6Tbps 的電信還不會 100%配到香港去, 看 CN2 才 10G, 更不能賺錢的 ChinaNet 能分到多少? 用最新的工藝開通 100Gx2 的信道也才 200Gbps 流量, 對於流量峰值已經超過 1Tbps 的 HKIX 還不算很嚴重。一次過接入 400Gx2 的話才要擔心, 不是交換中心跟不上, 而是亞洲區內接到 HKIX 的 ISP 線路容量不足。

然後更大的問題是: 對接香港的廣州國際局, 分配給電信的「安全裝置」容量追不上......

Japan Welcome SIM + 1, 最老實的因為是 NTT Docomo 自營, 價錢也不算貴, 而且免設定

很多所謂 NTT Docomo 網絡的 SIM 卡要加 APN(PAP 帶 username/password)的那種就不能用了, 只是買了很少出口頻寬 MVNO, 垃圾。

反而租用 U-roaming (Softbank 網絡)的 WiFi 還行, 今年去了日本兩次, 因為滑雪場算是遍遠地區, 住宿的 WiFi 都不太好, 兩個人幾台機要靠 4G WiFi, 兩次也用了接近 10GB 還沒遇到限速, MVNO SIM 卡的話早就限成 512kbps 或以下。

我們用 Japan Welcome SIM 方便分開行動時的聯絡, 一起時就共用 4G WiFi。

我是把家裡的 Subnets(LAN + VPN)都遠離 192.168.0.0/192.168.1.1, 考慮到經常用 VPN 連回去, 而外面很多一般路由器預設分配 192.168.0.0/24 及 192.168.1.0/24 為主, 避開了就好

已經有 3 點 LAN 之間的 site-to-site 互連, 還有 virtualization 的分隔, 但還是用不完 192.168.0.0/16

@imrei 我搞了電信+移動, 最後在 pfSense 的 firewall 順序是這樣

AS9808 -> 移動
AS9394-> 移動
chnroutes -> 電信
剩下的 -> VPN

@Danswerme 問題反一下, 把中國的路由表收集起來就可以了

https://github.com/fivesheep/chnroutes

chnroutes 的路由表, 用 iproute2 (ip route add) batch mode, 在一般的 LEDE 上五秒內完成。

還是嫌多就用 bestrouteb
https://github.com/ashi009/bestroutetb

一樓答案 +1

而且 WiFi 的情況比家寬好, 不會長期佔用 IP

我用 Intel n3150 (x86)的 NUC,裝 LibreELEC 的 Kodi, 再配個 Docker plugin, 進 linux shell 甚麼 Linux 的東西都能跑起來, 但價錢沒這麼便宜, 好處是 LibreELEC 很穩定, x86 build 長期有支持, 不像機頂盒般有各色小問題而要自己找方法解決。

上面說的都是 AMLogic S912 方案, 好像有 LibreELEC 的 rom 可以安裝, 但要配 docker 的話不知道有否這麼簡單了

@hlz0812 HKIX 是要交錢沒錯，但價錢一定比 Private peering/Transit 的低
價錢表是公開的: http://www.hkix.net/hkix/Charge/ChargeTable.htm
比任何一間 ISP 都要便宜吧?

當然沒免費的划算，但問題是有免費的嗎? HKIX 只收取基本的設備維持費用，開始的時候更是免費的，任何人接進去只要負責專線及路由設備的費用，到現在改成了自負盈虧也只按收費表計價。接入方法可以是跟 FTSN 租光訊道，也可以租 Layer 2 通道接進去。

其實 CN2 這麼久才直連 HKIX，要不是需求不大，就是以前成本沒在管都依賴 Peering 穿到 HKIX 去。