Re: [討論] 民視YT消失的44秒

看板HatePolitics作者menesn (迷思)時間4月前 (2023/12/21 23:19)推噓17(29推 12噓 161→)

留言202則, 39人參與討論串5/16 (看更多)

※ 引述《goldenfire (耶穌流刑獄情指黑中心)》之銘言： : 這位不知道是不是資工系畢業的 : 但至少我是 : 雖然英文不怎樣、計網當初好像也讀得普普而已 : 現在在做演算法博士 : 不過這一點基礎知識也還是有 : 先說結論：你的問題根本不是計網讀不好 : 而是應該要有點英文閱讀能力謝謝你還有 tsubasawolfy TonyQ femlro 的回覆你們是比較有誠意出來討論的因為每日發文限制的關係我統一回覆在這裡 : ※ 引述《menesn (迷思)》之銘言： : 直播者-----A------Youtube Server -----B----- 看直播的直播者跟觀看直播的是兩個傳輸點中間不管經過多少網路節點 TCP通訊協議的定義就是應該不掉包除非是訊號源有問題 : 這篇文章就講出來了 : "I was capturing youtube video packets using wireshark. I saw it was http : tunneled over tcp packet." : 意思是，他是看直播的，不是開直播的人 : Youtube這裡的串流技術，是指轉播的B部分其實StackOverflow問問題的人主要想了解的是YT串流技術的背後是使用哪一個通訊協定他甚至用Wireshark去抓包從封包的分析來看是http tunneled over tcp的封包底下有人留言當YT後來有針對如果有人在中間攔截串流的封包 (Man in the middle attack) 近期有特別做優化也有實作UDP的部分但是確實使用的協議是TCP The exact protocol is tcp; although YouTube has been switching over to UDP as of late : 所以Youtube為什麼不給你看，你要去問Youtube : 至於上傳端的部分 : 他們網頁就有寫了 : https://support.google.com/youtube/answer/2853702?hl=en : 上傳的部分是用 RTMP/RTMPS Streaming : 這部分就是使用UDP+TCP : 所以A部分掉包不要求重傳是很有可能的這個網頁主要是在解釋你在使用客戶端設定的時候加密器的設定 (Encoder setting) 這完全是在針對使用者介面做額外的說明而已雖然他有提到RTMP/RTMPS 但是我剛才打開我的YoutubeStudio https://imgur.com/O888fPj

他預設就是RTMP 你把選項點開也沒有RTMPS的選項給你選 RTMP背後也仍然是TCP : 你說的技術本身沒有問題 : 問題在於你連技術運用的對象是誰都不知道 : 是笨還是壞 : 就向民視陳經理說的 : 就交給大家判斷的你是演算法博士乃是國之棟樑也是知識份子的代表大家理性討論也無需要用言語去貶低別人酸說英語能力不好貶低別人可以滿足自我的優越感但是無益於理性討論與交流也不會增加閱聽者對您的尊敬只是同溫層看到貶低不同意見者會很爽而已我在美國求學跟科技業共七年不敢說自己英語能力有多強但是看技術文件是絕對足夠的 --- 至於tsubasawolfy 在回文中提到中間網路節點伺服器以及VOD 其實也只是想混淆視聽而已以通訊協議的定義來看同一個點(都在民視直播間) 的區域網路送出去的封包送往FB的沒有中間截斷但是送往YT的確被中間截斷 (長達44秒) 代表這個區域網路並沒有電力中斷或者網路中斷等的現象發生唯一可能就是送出訊號源到YT的這端有發生人為中斷訊號的現象 : 訊號不穩，觀眾端一定會LAG，VOD會留存到大lag前為止這個腦捕的太嚴重了不得不說觀眾的客戶端是瀏覽器或者移動端的APP 根本沒有用到VOD(Video On Demand) 你到底想要偷渡甚麼概念? 觀眾的手機或者電腦是要開甚麼VOD來側錄影片? 不要騙不懂技術的人 : 第一個如果像這PO說的，民視那邊有人手動斷開直播連結，那直播會被切成兩段才對 : 因為直播結束就結束了，你要重新拿一個新鑰匙你以為我沒有用YT直播過嗎? 串流金鑰改變了所以呢? 你民視有在串流的時候同時螢幕錄影然後告訴大家說喔我串流的金鑰沒有變證明我沒有手動切斷如果有我很樂見民視公布完整的螢幕錄影 --- 至於TonyQ 的回文 : 而且這裡說的包是很多很微小的 bytes[] ，不是一整個影片。 : 所以不會因為你用了 tcp 就不掉包。下略很多字。我講得包是Packet 一個Packet有64K bytes也不是甚麼微小數目了 44秒是真的很大一段接下來你開始檢討應用層有問題如果是應用層有問題歡迎你提出，或者請民視提出到底哪個用戶真的在同樣的YT直播收到完整的沒有44秒被中斷過的證據最後你開始檢討YT後端伺服器有問題老實說我寧可相信YT工程師的實力遠遠超過民視在操作直播的技術人員我也自忖沒有這個實力去檢討YT後端開發會有甚麼問題因為我很明白這個領域的專業度 (或許16年網頁工程師做過串流有這個技術水平來指點一二? 你要把程式碼拿出來Review嗎? 我奉陪) 有人que我要回復TonyQ再推文的留言以下是我看過後的回覆(12/22 9:11分左右) : 要做到即使斷線也不掉包，就是犧牲即時的速度， : 且要加上訊源端要能夠儲存足夠多cover中斷時間訊源的空間，另外再堆疊協議做到。甚麼叫做 : 堆疊"協議" 我真是孤陋寡聞了還有這種說法，你是寫甚麼code在應用層堆疊"協議"? : 問題是，這實際上跟先 buffer 個 n 分鐘再開始播， : 或者乾脆錄好事後再播的邏輯差不多了。 : 他是不是定義上的直播我都覺得問號。訊號源要碼是使用YoutubeStudio的網頁介面或者用OBS Studio或者Xsplit這些桌面應用層式 (這些都是很成熟的商業軟體喔為什麼民視經理不說喔，那是我們使用的客戶端軟體有BUG 而是把問題推到YT身上?) 其實你提這麼多就是想牽拖說阿這邊有問題那邊有問題但是你忽略一個重點就是同樣環境同個時間點串流到臉書的居然沒問題所以你去扯應用層網路環境都是在打假球而已 : tcp 不會掉包是嚴重的謬論你在不同地方不斷提出但是從來沒有解釋是怎樣的謬論 : 至於有沒有什麼是接收方（youtube）的環境問題，也是有可能的， : 甚至中午有人要加碼懷疑是ISP搞鬼，理論上也是有可能的。請問民視直播間是用哪一間ISP? : 我們當前每個雲平台都有掛過一個小時以上的紀錄，gcp/azure/aws， : 我是覺得以他的量體來說，這些 edge case 我不覺得是容易抓完的問題。我不確定你說的"我們"是指民視的網路技術部門還是你現在工作的公司雲平台掛掉一個小時絕對不是AWS/GCP/Azure的問題而是身為使用者的你們技術力太弱? 拜託民視YT直播有多少人看? YT有過多少更大型的直播use case 你字裡行間真的自以為技術有多強也有沒有github帳號給眾網友瞻仰一下 : 以我自己用 rtsp 的經驗應該是可以續傳的，只是中間會有中斷。 : 是不是第二個直播，這是 ap 層的實作問題，與傳輸層無關。中間有斷跟掉封包是兩回事你難道不清楚嗎? 還是故意語焉不詳來呼嚨閱聽者 : 我個人是覺得要怎麼陰謀論都可以，但是不要無視 ap 的風險， : 不要硬要鬼扯 TCP 一定不會掉包，或是 UDP 一定會掉包。我還在等你解釋"tcp 不會掉包是嚴重的謬論" 甚麼叫做"無視 ap 的風險" AP層有問題串到FB那邊的也會有問題啦我早就提出質疑你能否證明民視串流到YT跟FB 是在不同的區網還是不同的串流客戶端到現在也沒有解釋不是技術很強? 為什麼選擇性忽略? : 事實上我自己就偶爾會做流量大就放推的設計（遮臉）應用層的設計嗎? 還是傳輸層的實作? : 可能性太多了，硬要我猜的話， : 我個人推測會覺得是接收端那邊的 application 應該是被重分配了。 : 類似 container 被卸載重上之類的概念， : 所以出現了比較明顯的 downtime。你以為拿普通人看不懂的名詞出來講就可以唬弄過去甚麼叫做接收端的application被重分配? 你的意思是YT伺服器把串流導到接收端的時候出現分配不均勻的狀況嗎? 換言之，有些封包到了A點，有些封包到了B點 (A, B都是終端) container被卸載重上接收端是哪裡有container啦胡說八道 container(容器)在軟體工程是專有名詞舉例，瀏覽器跟移動端的APP都是直接安裝在原生的作業系統上裡面並沒有內建容器 : 我當了那麼多年的軟工版板務。XD 所以你16年網頁工程師做過RTSP兼軟工板務嗎? 歡迎你把我的文章轉到軟工板讓那邊的網友們檢視 : 這篇在軟體相關看板也撐得住的啦。 : 資料庫那段是在舉例應用實作的影響你是串流串到資料庫裏面嗎? --- 至於femlro 你寫得內容其實也就只是把網路的一些概念擷取一部分寫出來告訴網友，喔其實這些網路不同的分層應該是這樣子運作的啦然後最後在天來一筆說因為前面這樣那樣所以太可能是民視手動干預懂技術的人看了就會覺得你前面是在講廢話嗎? 然後結論到底怎麼突然跳出來這跟民進黨政府先編預算在編計畫的行為有八十七分像你是，先想好結論，再編理由只是編的理由，漏洞百出 : 一個訊源三個輸出中有一個出現44秒的中斷 : 可能涉及到特定的應用層設定、伺服器資源管理、甚至是網絡路徑上的特定問題我前面提到很多次可能你沒看懂一個訊號源在同一個區域網路一個輸往FB終端一個輸往YT終端結果一個有問題一個沒有那代表的就是伺服器資源管理正常網絡路徑沒有阻塞至於應用層我就說呀民視經理在全國媒體面前說有人收看沒問題你們提得出證據嗎? 有人在你們YT頻道直播的時候，看到"被消失的44秒嗎"? 不要只會貼甚麼二次元直播主啦球賽啦這種直播視頻跳秒數的影片來混淆視聽想要帶錯誤概念直播視頻跳秒，跟掉封包完全是兩回事認知作戰也要拿出點水準來如此低劣 -- 大道之行也，天下為公，選賢與能，講信修睦，故人不獨親其親，不獨子其子，使老有所終，壯有所用，幼有所長，鰥寡孤獨廢疾者皆有所養；男有分，女有歸，貨惡其棄於地也不必藏於己，力惡其不出於身也不必為己，是故謀閉而不興，盜竊亂賊而不作，故外戶而不閉，是謂大同。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.227.22.248 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/HatePolitics/M.1703171968.A.D0B.html ※ 編輯: menesn (36.227.22.248 臺灣), 12/21/2023 23:31:23

推

yuchihsu

12/21 23:23, 4月前 , 1^F

12/21 23:23, 1^F

噓

cystal

12/21 23:24, 4月前 , 2^F

12/21 23:24, 2^F

→

cystal

12/21 23:25, 4月前 , 3^F

12/21 23:25, 3^F

推

hsuyusheng

12/21 23:26, 4月前 , 4^F

12/21 23:26, 4^F

→

goldenfire

12/21 23:26, 4月前 , 5^F

12/21 23:26, 5^F

→

goldenfire

12/21 23:26, 4月前 , 6^F

12/21 23:26, 6^F

通訊協議要看一手的資料 https://reurl.cc/RW4D4G https://reurl.cc/j37p52 這邊講得又更明確了 A TCP-based transport would be vulnerable to similar attacks. Since there is no PKI, this profile gives no guarantee that the client has actually connected to the desired server, versus a rogue or man-in-the-middle. ... RTMP messages were originally designed to be transported over RTMP Chunk Stream in TCP [RTMP]; however, other transports (such as the one described in this memo) are possible. 跟我之前提到的以及原始連結 StackOverflow網友提到的 YT後來為了防止有人擷取兩個端點串流的封包而做得改進你要討論的更細節或者拿程式碼出來看我都可以奉陪沒有必要說我在造謠甚麼的今天很明顯造操作風向的是民視我只是看不下去用自己的時間來寫這些

→

CHENXOX

12/21 23:27, 4月前 , 7^F

12/21 23:27, 7^F

推

orinsinal

12/21 23:28, 4月前 , 8^F

12/21 23:28, 8^F

→

orinsinal

12/21 23:28, 4月前 , 9^F

12/21 23:28, 9^F