可能已經有很多人會了@@ 我是無意中發現的，所以分享一下，如果有需要寫詳細一點再跟我說: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