可能已经有很多人会了@@ 我是无意中发现的，所以分享一下，如果有需要写详细一点再跟我说:D icecast设定档官方说明文件(英文) http://www.icecast.org/docs/icecast-2.3.2/icecast2_config_file.html icecast的设定档里面针对每个mount点可以做不同设定， 其中有个参数叫做fallback-mount 大概的意义是如果听众听一半source断掉了，或者根本连上去时就没有source， 会自动改播设定好的另一个mount点。 还有个参数叫做fallback-override， 这个的用途我就比较不确定，大概是如果原来的mount点source恢复了，就回去播。 这样讲很乱，来个实际例子比较快 例如： <mount> <mount-name>/live1</mount-name> <fallback-mount>/live2</fallback-mount> <fallback-override>1</fallback-override> </mount> 我的mount点叫live1 如果live1挂了，会自动改播live2， 所谓「自动」是指听众不会断线，直接变成播live2的source。 如果这时候live1又突然好了，听众会直接播回live1的source。 附注一下，如果要成功让icecast「自动」切换播放， 备用mount的source stream的格式(ex.mp3)和bitrate(ex:128kb/s) 最好跟原来的mount点一样，以免造成断线的可能。 ==================I'm 好短分隔线======================= 所以这到底跟延迟有什麽关系？ 用以上的例子来讲， 假设用SAM的话，我们可以同时连上/live1和/live2 （用一模一样的设定） 这时，当我们遇到一些需要听众降低延迟的情况， 在SAM中对/live1停止encoding 这时听众们会切换到/live2 然後我们又再重新继续对/live1作encoding 听众又切回/live1了 (我切过来了，我又切回去了，打我啊笨蛋 过程中听众声音会跳一下，那个时间差就是抓回来的延迟 这样到底可以降低听众多少延迟呢？ 我自己在本机上测试(自己播自己听= =)大概是抓回 0.8 ~ 2 秒 视你的bitrate而定。 =================分隔线再现============== 这样真的有用吗？ 到底发生了什麽事情？ 首先我是在本机测试，如果icecast和source(SAM)在不同主机的状况， 这个方法是会更有效还是无效我不确定，有时间我会测一下。 至於原理我不是非常清楚，但是可以猜个大概。 听众的软体在连电台的时候多少会抓一点buffer，这个是造成延迟的主因， icecast可以把sever端的缓冲区关掉，可是就算这样，听众的软体也还是会先 停一下下载几k的buffer才开始播放。 而当我们进行以上所述的mount点自动切换的时候， 理论上听众端不会重新抓buffer，因为软体通常只有两种时候会抓buffer： 1.开始播以前 2.buffer几乎快播完了，有些软体会暂停播放再抓一些buffer再继续播 那我们从/live1切到/live2的时候 我们/live1又重新encoding了，icecast server上 /live1 刚有资料冒出来 icecast就立刻把听众切回/live1了， 所以听众视网路情形会听到比较接近即时的source 大概原理可能是这样 (不负责任发言XD||| /* 打完这篇文章我又测试了一下(还是本机) 如果你一直重复encoding开始/停止数次的话， 是有可能抓回3秒以上的， 但是声音在这个过程中会"跳跳的"，如果你做节目时有急需降低延迟倒是可以考虑一下 */ -- --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 211.20.132.89