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

※ 引述《femlro (既得此生當盡其用)》之銘言： 不是啦 怎麼還在講這個 情況其實很簡單 民視有一個原本受中選會委託的實況 https://m.youtube.com/watch?v=aMVbIa1tM-o 我們簡稱為A 據民視網路部經理自己到場所言 他們會把這個類似母帶的原訊號 分送給三個地方 中選會、各家媒體、以及自己內部 然後這次出事的是民視內部再次上傳的快新聞版本 也就是左上角加了節目標的影片 https://www.youtube.com/watch?v=JcmSEULfxNg&t=5196s 網友友善備份在這 https://m.youtube.com/watch?v=qgLVaxAqoB8 你當然能說 「啊我就眼殘沒注意到中間落了44秒 我上好快新聞字樣就送出去了」 然後說是YT再次協握機制有夠爛 怎麼偏偏只搞你 但閱聽大眾不管你啊 我們只看到 你再次上傳的快新聞版本 就是長得跟別人不一樣 而且你還有自己的母帶完整訊號源打自己臉 這樣 有搞懂嗎 we never know 因為你不願意把那片影片解開私人 所以只有備份 你打算死無對證 我們閱聽大眾當時看到的只是 你再次上傳的影片版 連標題都沒改的版本 卻少了44秒 然後其他媒體源的通通沒事 就這樣而已 好 民視請解釋吧 題外話 https://www.youtube.com/watch?v=hB5XTcf4mkY 老天鵝這集真的臭XD https://i.imgur.com/9Uq6J39.jpg : TCP和UDP的可靠性： : 雖然TCP提供可靠性保證 : 確保Date Packet的順序和完整性 : 但並不能防止網絡斷線 : 斷線後 : 必須重新建立連接 : UDP則不保證數據的順序或完整性 : 適合用於延遲敏感的應用 : 如視訊和語音通話 : Data Packet: : Loss data packet不僅局限於大型文件或影片 : 而是涵蓋了所有通過網絡傳輸的data packet : 無論大小 : 這些小型data packet丟失也會影響應用層的性能和可靠性 : 應用層的實作和AP的性能： : 網絡層的協議僅能保證數據在網絡上的傳輸 : 而應用層的實作則是決定數據 : 如何被處理和儲存的關鍵 : 伺服器的負載、記憶體資源、以及其他硬體和軟體因素 : 都會影響應用的性能和穩定性 : 應用層和協議層的關聯性： : 討論像是搶票平台或其他高流量應用時 : 通常會遇到伺服器負載過重或資源不足的問題， : 這些問題的確和網絡層的協議只有間接關聯 : 應用層的設計和實作才是確保性能和穩定性的主要因素 : 一個訊源三個輸出中有一個出現44秒的中斷 : 可能涉及到特定的應用層設定、伺服器資源管理、甚至是網絡路徑上的特定問題 : 手動干預的可能性雖然存在 : 但通常會首先考慮技術和配置方面的原因 : 網絡通訊和應用性能時需要考慮從低層的網絡協議到高層的應用實作 : 以及它們之間的相互作用和依賴 : 結論就是不太可能是民視手動干預 : 可能性很低 : 只是他恰好發生在柯文哲很重要的言論時刻 : 讓人會非常懷疑 : 就好像人不是你殺的 : 結果你剛好送報紙當天買水果刀準備回家切水果吃 : 很難不被人懷疑 : 但不代表是你做的 : 實在沒必要糾結這種事情 : ※ 引述《TonyQ (得理饒人)》之銘言： : : ※ 引述《menesn (迷思)》之銘言： : : : 直播者跟觀看直播的是兩個傳輸點 : : : 中間不管經過多少網路節點 : : : TCP通訊協議的定義 : : : 就是應該不掉包 : : : 除非是訊號源有問題 : : TCP 是有可靠性，但是 tcp 防不了斷線，這是常識， : : 當你斷線就是得 reconnect 。 : : 你隨便寫個 socket/server socket 然後拔網路測測看， : : 你就知道我在講什麼。 : : 而且這裡說的包是很多很微小的 bytes[] ，不是一整個影片。 : : 所以不會因為你用了 tcp 就不掉包。下略很多字。 : : : 其實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 : : 這些其實都不太重要，首先不管 udp or tcp ， : : 他都有因為網路環境的影響（不只是發送端的上傳，也要考慮到接收端的下載）。 : : 或者是伺服器當時的 ap 是否有足夠接收的能力， : : 比方說伺服器 ap 記憶體不足、負載過重等等，都可能導致接收端出問題。 : : 我是不知道你們拿超底層的協議，在討論上位的 application 行為有什麼意義， : : 因為協議能確保的只有 bytes 能傳輸。 : : 他連檔案能不能被正確儲存、訊號能不能被轉發，都是要倚賴 application 的實作。 : : : 雖然他有提到RTMP/RTMPS : : : 但是我剛才打開我的YoutubeStudio : : : https://imgur.com/O888fPj

: : : 他預設就是RTMP : : : 你把選項點開 : : : 也沒有RTMPS的選項給你選 : : : RTMP背後也仍然是TCP : : : 你是演算法博士 : : : 乃是國之棟樑 : : : 也是知識份子的代表 : : : 大家理性討論 : : : 也無需要用言語去貶低別人 : : : 酸說英語能力不好 : : : 貶低別人 : : : 可以滿足自我的優越感 : : : 但是無益於理性討論與交流 : : : 也不會增加閱聽者對您的尊敬 : : : 只是同溫層看到貶低不同意見者 : : : 會很爽而已 : : : 我在美國求學跟科技業共七年 : : : 不敢說自己英語能力有多強 : : : 但是看技術文件是絕對足夠的 : : : --- : : : 至於tsubasawolfy : : : 在回文中提到 : : : 中間網路節點伺服器 : : : 以及VOD : : : 其實也只是想混淆視聽而已 : : : 以通訊協議的定義來看 : : : 同一個點(都在民視直播間) : : : 的區域網路 : : : 送出去的封包 : : : 送往FB的沒有中間截斷 : : : 但是 : : : 送往YT的確被中間截斷 : : : (長達44秒) : : : 代表這個區域網路 : : : 並沒有電力中斷 : : : 或者網路中斷等的現象發生 : : : 唯一可能 : : : 就是送出訊號源到YT的這端 : : : 有發生人為中斷訊號的現象 : : 伺服器上可能出問題的東西太多了，你完全沒有考慮到 application 層的問題。 : : 比方說舉個例子好了，搶票平台很常被塞爆，大家都只能看 500 ， : : 這是因為 connection 過多導致db 處理過重或者是其他因素。 : : application 的實作才是這中間最大的 factor， : : 跳過這件事情直接談結果本身是很奇怪的事情。 : : https 當然是 tcp，但他也不代表他就能正常回應， : : 關鍵還是回到 ap 的實作跟接收能力。 : : 你說你做過服務然後你完全假設 ap 是能正常回應， : : 把問題限縮在底層 protocal ，這實在是太奇怪了。 : : 正常情況下其實 os loading 跟 ap status 才是第一個會被確認的吧。 : : 這次最奇怪的就是一堆人抓著超級底層的架構在討論一個很上位的明顯 ap fail。 : : 重點是這次按照揭露資訊是一個訊源三個輸出只有其中一個掛44秒。 : : 在推斷上也很難得到這是手動為之的結果， : : 不能說100%不可能，但是很難想像。 ----- Sent from JPTT on my iPhone -- 男孩回到了現在， 15年來，第一次成功地將自己對女孩的感情說了出口。 男孩的願望已經結束，原以為奇蹟之門再也不會向他打開， 但是── 那扇沉重的門扉，還是被女孩打開了。 究竟，幸福會不會降臨到這兩人的身上呢？ 《求婚大作戰 SP》 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 27.242.128.133 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/HatePolitics/M.1703209569.A.CE3.html