前言 Adobe Flash Media Live Encoder (FMLE)，作为一套老字号的串流直播软体， 虽然有着高系统资源消耗的缺点，仍然在实况直播的社群中保持着相当的市占率─特 别是停留在WindowsXP的使用者和Mac的使用者，对他们来说没有选择OBS和FFSplit的 机会。(XSplit那个明明就用别人家的x264还要收钱的东西，虽然市占率高到爆炸， 但是我实在不想放在这里比较...) 2013年12月中的影片系统更新之後，听到不少朋友反应说FMLE没办法用啦、一直 断线啦、画面都马赛克啦，之类的状况。因为觉得这跟用哪个软体应该没有关系，所 以决定装上FMLE来实际测试一次。(虽然我猜大概有不少人仍然在继续用FMLE而且没 感受到任何问题。...至於为什麽必须要用FMLE，当然是因为没有Win7可以装。...) 这篇文章会分成两个部分。前半部描述FMLE要怎麽样调整设定值来进行低画质实 况，後半部描述进行低画质实况的理由、和一些安排画面的考量方式。 研究动机 某实况主表示十二月底开始就没办法用FMLE开台给友人PK丸(pk152)看。 研究目标 能够让PK丸看到的影像顺畅播放。(PK丸的下传流量最大值约600kbps) 实作方法与结果 假定要让下传600k的PK丸能够顺畅播放，那目标应该是把传输量控制在80%以下 ──因为他很可能还是会一边开个其他网页或是丢讯息，所以目标设定在480k附近。 因此采用以下三种情况，并附上实测影片片段。 (以下的xxx+64kbps的xxx是影像的频宽，64kbps是声音的频宽) (1) 240p低画质: http://twitch.tv/append/c/3494901 320x240@30fps 350+64kbps H264 Profile:Main Level:2.0 KeyFrame:2sec (2) 360p中低画质: http://twitch.tv/append/c/3494922 480x360@20fps 400+64kbps H264 Profile:Main Level:2.1 KeyFrame:2sec (3) 360p中低画质宽萤幕: http://twitch.tv/append/c/3494941 640x360@15fps 400+64kbps H264 Profile:Main Level:2.2 KeyFrame:2sec 软体除了FMLE 3.2进行编码以外，画面撷取是用SCFH DSF 0.4.1。 H264的Profile固定为Main，Level尽可能选择最小值(反正太低FMLE会告诉你)， Keyframe Frequency固定为2 seconds， 声音的设定固定为MP3/Mono/44100Hz/64kbps。 讨论 Twitch对於实况的要求其实很少：影像只要求H264、固定位元率(CBR)和2秒的关 键影格间格，声音只要求44100Hz，AAC或MP3，设定上限─但是压低流量的情况下显 然会自动满足。对於先天满足CBR的FMLE来说，需要更动的部分其实非常少。 如果仔细看会发现我在放大解析度的同时把FPS降低了。这让画面不那麽流畅， 不过这是为了在尽可能的节省频宽的情形下维持影片的可读性。特别是宽萤幕的情况 下，为了让影像从480拓宽到640，只好让FPS照比例缩小到3/4，从20fps变成15fps。 然而，人眼只要FPS超过10-12左右，就会认为影像是连贯的[1]，所以我相信15fps虽 然对注重画质的人来说虽然差强人意，但是这个妥协点应该会被大多数人接受。 上面列出了三组不同解析度的设定值，然而影像解析度在不同状况的时候应该要 开多高呢？在这点上我多描述一些我对於实况串流的想法。我觉得一个实况主有义务 要适当的安排自己的画面，计算清楚自己的画面要用多大的解析度，还有观众在观看 的时候会占多大的版面。上面这三点可以分开来讨论： (1) 播放什麽画面or玩什麽样的游戏： 举例来说，玩红白机马利欧或洛克人，却开1080p或是720p实况的，实在令人难 以忍受──红白机的原生解析度是256x240，开到360p以上根本就是放大画面来增加 传输的困难；放大画面应该交给对方的浏览器来办到，来节省传输所需的资料量。但 是如果玩的游戏是LoL，原生解析度1080p，画面中又充满了文字，那720p很可能就是 必须的，或是压到480p的同时利用Lanczos压缩的特性来强调文字的边缘，让文字稍 微清晰一些。 (2) 画面上除了游戏以外，有那些东西必须要清楚的放出来： 这边讲的其实主要是"文字"。现在有很多实况主会喜欢把聊天室放到画面上， 例如：http://i.imgur.com/uBlIJDM.png (聊天室+点歌系统) 输出之後文字在画面上占多少像素才能够清楚的看到，用无衬线的粗体比较不怕 糊，这些都应该事先计画好。然而，官方预设的聊天室常常无法满足这些需求，因此 上面例子中的聊天室使用的是"IRCBalloonJ"，是个为了TTV/JTV聊天室而设计的IRC 软体。现在网路上能够找到的IRC软体很多，例如繁体中文区常见的IRCBalloon、拥 有大量脚本的mIRC、能够搭配NicoLime形成弹幕的LimeChat、还有我现在较常使用简 单乾净的JTChat，都能够配置成不错的版面。例子中还有正上方的一行当前歌曲播放 名称，那其实是NightBot的点歌系统，然後用OBS内建文字撷取来放在画面上的。 另外，由於最近Twitch加长了延迟时间，有一些Twitch实况主开始尝试移动到 Hitbox上进行实况；由於Hitbox的聊天室目前并不是使用IRC协定，所以是没有办法 用这些IRC聊天室软体来安排在画面上的。虽然OBS使用者很可能可以透过CLR浏览器 +CSS修正来做出类似的效果，但是Hitbox官方表示聊天室正在大幅修改，所以我目 前暂时没有仔细研究的打算。 (3) 要给那些人看这个画面： 这牵涉两个层次。第一个是如同本文一开始举的例子：我想让友人PK丸看实况， 他的下传最高只有600kbps，所以我控制在80%，也就是480kbps附近。虽然光纤宽频 已经算是常见的，但是仍然有不少使用者没有很好的网路─特别是那些跟邪恶P2P使 用者住在同一个屋檐下的勇者们。频宽控制的越低，能够无压力的观看的人就越多。 第二个是，收看者会用什麽画面来看实况影片。举Twitch的例子来说，官方介面 旁边是有聊天室的；如果你相信你的观众平常都会开着聊天室，或你期待你的观众参 与聊天，他们势必不会开着全萤幕的影片。也就是说，1080p的影片根本就不会完整 的被人看到。 下面举些常见的例子，来检查一下实际上大概到底有多少空间可以用。 Twitch官方介面(功能列开启):可视空间1280x720 http://i.imgur.com/TVDbZMc.jpg Twitch官方介面(功能列关闭):可视空间1470x800 http://i.imgur.com/RYVHE3D.jpg GNBOX介面:可视空间1610x870 http://i.imgur.com/g58lJeM.jpg 皮克直播介面:可视空间1596x892 http://i.imgur.com/XpU7Hjs.jpg 从以上数据看起来，假设你的观众有很大部分看皮克实况，那设定1600x900就有 意义──这数值非常接近了。但是如果你的观众会从官方介面来，超过720p的部分就 很难看到，那样就只是纯粹在浪费大家的频宽。就算是在玩1080p的游戏，原尺寸输 出也没什麽意思──除非你希望你的观众放弃聊天室。 结语 这篇文章以FMLE和友人PK丸为例，描述了低频宽低画质实况的设定方式；根据友 人PK丸表示，三组设定值的播放都相当顺畅。同时，这篇文章也讨论了一些画面安排 上的考量方式，希望能够避免掉一些无谓的频宽浪费。 平常我们常说节约用电、节约用水、节约使用自然资源之累的事情，我觉得在现 在这个时代中，「网路流量」也已经是一种并非私人所有的共用资源；以Twitch为例 ，台湾连到Twitch的总流量显然有所局限，即使没有明确的消费或是频宽限制进行约 束，使用者也应该要能够掌握、同时控制流量，避免不必要的频宽浪费。更进一步的 说，实况主如果能在合理的范围之内降低上传的频宽，那观看这个频道所需要的门槛 就会降低一些，进而更有机会吸引到原本没办法看的观众。希望这样一篇文章能够对 大家有所帮助。 Append. 2014.01.04. 23:43 p.m. UTC(+0) 注： [1] 出自"Restoration of motion picture film"第24页。 http://goo.gl/gwEg5X -- ███◣ ◢██◣ ◢██◣ █ ◢█ ◣ ◢ ◢██◣ ◣ █ █ ██ █ ██ █ ██ █◢█◤ █◣◢█ █ ██ █◣ █ █ ██ █ ██ █ ██◤ ████ █ ██ ██◣█ @ ptt.cc ███◤ █ ██ █ ██◣ █◥◤█ ████ ████ █◥█◣ █ ██ █ ██ █◥█◣ █ █ █ ██ █◥██ 鸦片(Append) █ ◥█ ◥██◤ ◥██◤ █ ◥█ █ █ █ ██ █ ◥█twitch.tv/append --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 5.65.151.228 ※ 编辑: Append 来自: 5.65.151.228 (01/05 07:43) 根据 http://goo.gl/Jtp5YZ Twitch官方Blog在20131213放出来的消息说 we've increased the latency by multiple seconds to make sure that we're delivering smooth video. 总之他们为了确保大家可以更顺畅的看到那些影片(意思是不会断一下断一下) 增加的延迟的时间 然後在 http://goo.gl/y0GYo7 同样 官方blog 在20131220放出来的消息 他们统计了Dreamhack Winter 2013的转播数据 认为新系统非常成功 使用者中断串流进入缓冲区间的次数 跟旧系统相比 少了非常多 这边的Dreamhack Winter 2013应该是一系列的电竞转播， 因此我觉得Twitch的目标如果是这个社群，他们优先放弃即时性是非常正确的； 但是对於重视互动的小型社群来说，这阵子就会过得非常痛苦。 1220那个时候他们认为那时的延迟大概分布在12-40秒不等， 然後这个延迟是"有可能"下降的─他们声称会让工程师致力於解决这问题； 但是我其实不太相信他们会让他回到10秒内。 我目前对Twitch/Justin上的社群观察，大致上可以用四种模型描述： http://i.imgur.com/8MkevlM.png (注解一下。一个社群有可能介在某两个Type之间，而且这个比例会随时间变化) 然而在这些社群之中，最能够为Twitch带来收入，也同时使用最大宗的流量的， 应该是Type1的那些串流。他们需要节目内容的品质，但是不需要即时性。 所以我觉得Twitch把延迟时间加长是很符合他们的需求的， 同时我不太相信Twitch会有兴趣把这个平衡拉回来照顾其他Type的社群。 ※ 编辑: Append 来自: 5.67.248.183 (01/06 20:20)