vscode

https://1.1.1.1 了解一下

看 developer doc 找到 cloudflared, 那工具可以做到 dnsproxy, 移動到 1.1.1.1 走香港節點

ER-X+1, 網管及 PoE 都兼顧到

但我也有一隻 Ubnt toughswitch(老款)放在無 220v 供電的室外弱電箱做 PoE 配電, 不用 PoE 的話 BL-SG108M, 這貨我在室內用也很好

早期階段, 直接找「手機軟件工程師」去支撐「手機軟件*平台*」, 這看來是「只差一個工程師」的節奏....

既然是平台, 那定必涉及到管理用的前端+後端+終端, 一個工程師肯定是不夠的

前端 <- 給平台人員用的, 還有業務的 www 網頁
後端 <- 伺服器, 上面要跑支撐平台的程式
終端 < -手機只是終端

而且, 光是聽這種介紹就感覺到項目人對 IT 產業的基本認知不足, 不談利益要吸引大佬們也要有一個專業方向吧, 看了完全沒有興趣花時間來詢問, 如果你的項目很容易因為幾句介紹就被抄襲, 那聽起來也不算是很獨特的商機 ......

如果「手機軟件平台」只是 App delivery platform, 那你作為學生黨基本可以死心了。就算是 Facebook 剛開始的時候, 也只是解決自己學校的交友需求, 然後才擴張的。

回到老問題: 你倡議的平台要解決啥米問題呢?

Hey I am interested, how about I contact you in person? I will stay in Cambridge for a while. Please reply with your address.
--
鵝湜崍看牠咋樣茴應 di, 姐 4 勺魚

現在應該學會了 cross-compiling 了吧......

make 這事情, 做了一段時間覺得時間太長, 又不敢 Ctrl-C 按停放棄進度來調整, 結果就是在刷時間紀錄 囧

@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。