Re: [讨论] 民视YT消失的44秒

楼主: mcharuko (象)   2023-12-22 09:46:05
※ 引述《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
: : : 你是算法博士
: : : 乃是国之栋梁
: : : 也是知识份子的代表
: : : 大家理性讨论
: : : 也无需要用言语去贬低别人
: : : 酸说英语能力不好
: : : 贬低别人
: : : 可以满足自我的优越感
: : : 但是无益于理性讨论与交流
: : : 也不会增加阅听者对您的尊敬
: : : 只是同温层看到贬低不同意见者
: : : 会很爽而已
: : : 我在美国求学跟科技业共七年
: : : 不敢说自己英语能力有多强
: : : 但是看技术文件是绝对足够的
: : :

Links booklink

Contact Us: admin [ a t ] ucptt.com