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。

我是把家裡的 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