8个关于SRT的误区
生活随笔
收集整理的這篇文章主要介紹了
8个关于SRT的误区
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
SRT誤區1:SRT未被廣泛采用
從廣播巨頭Sky News,福克斯新聞和NBC體育到業界巨頭如Avid,MediaKind和微軟,SRT無處不在。得益于不斷增長的用戶和開發者社區以及開源計劃中VLC,GStreamer,Wireshark和OBS Studio的采用,SRT正迅速成為廣播和流媒體行業事實上的低延遲視頻流標準。SRT聯盟有200多名活躍成員(并且還在增長[2]) 以及數百種SRT就緒解決方案 - 從攝像機、編碼器和解碼器到網關、OTT轉碼服務和CDN。SRT目前已在全球數千個組織中部署在許多應用程序和場景中。不要只相信我們的話,多讀一些有關如何SRT運用SRTHub在行業中例子,關注下2017年的NAB就知道了。
SRT誤區2:我需要購買使用SRT的許可證
不要與其他昂貴且封閉的專有協議混淆,SRT可以使用免費的開源代碼庫實現,從而保持所有使用方低成本。沒有長期合同或月租費。開源是鼓勵SRT的廣泛采用,有助于確保最終用戶的互操作性和使用壽命,同時避免供應商“鎖定”。這是最好的合作。
SRT誤區3:SRT不支持所有視頻編解碼器
與特定視頻和音頻格式的其他協議不同,SRT不限制您使用特定容器或編解碼器,因為它與媒體或內容無關。SRT在網絡傳輸級別運行,充當您內容的包裝器。這意味著它可以傳輸任何類型的編解碼器,分辨率或幀率。這很重要,因為它可以將MPEG-2,H.264和HEVC無縫一起工作來實現未來的工作流程。
SRT誤區4:SRT無法通過互聯網傳輸4K視頻
同誤區3,SRT協議與內容無關的,可以完全支持4K UHD和HD視頻。例如Haivision的Makito X4視頻編碼器專為超低延遲4K和HD視頻而設計,包括對SRT協議的原生支持。這使其非常適合在不可預測的網絡(如公網)上進行流式傳輸。通過內置的AES 128/256位加密,SRT允許Maktio X4用戶保持4k內容的加密安全性。
雖然SRT最初設計用于解決流媒體視頻內容在互聯網上的主要挑戰,但一旦開源后開發人員就開始在自己的硬件和軟件堆棧上為所有類型的網絡實施SRT。除了公共互聯網之外,SRT還可以用于管理網絡,如MPLS以及衛星,SD-WAN和蜂窩網絡。您可以在此博客文章中詳細了解SRT的多樣性:使用SRT通過Internet和其他網絡實時流式傳輸[3]。
恰恰相反!將OTT延遲降低到廣播電視水平的競賽中,SRT扮演著至關重要的角色。 ?雖然低延遲流的爭奪在最后一公里不斷加速,內容被傳遞到屏幕上觀看,但事實是低延遲的勝利開始得更早,在第一英里。在覆蓋遠程事件時,第一英里的流媒體包括從攝像機捕獲內容,通過H.264或HEVC對其進行編碼,并通過IP網絡將其流式傳輸到生產設施。也稱為廣播傳輸,此階段對于管理整體端到端延遲至關重要,SRT包括適用于第一英里的主要功能,包括低延遲丟包恢復和內容加密。SRT可以在第一英里和最后一英里保持低延遲,支持在HLS,MPEG-DASH和CMAF及ABR動態碼率。
SRT誤區7:SRT不能與RTP互兼容操作
SRT允許您可靠、安全高效地傳輸RTP,因此您可以絕對利用SRT,同時維護現有的基于RTP的廣播基礎架構。
SRT誤區8:SRT僅支持高達30 MBit/s的碼率
SRT中曾經有一個默認設置,它將SRT使用的最大帶寬設置為30 MBit/s。這只是曾經默認值,可以設置為任何其他數值,例如100 MBit/s用于支持輕度壓縮的傳輸視頻和4K UHD工作流程,或5 MBit/s用于低帶寬流式傳輸。在最新的SRT版本(v1.3.3[4])中,默認值已提高到1 Gbps。
LiveVideoStack? 招募
LiveVideoStack正在招募編輯/記者/運營,與全球頂尖多媒體技術專家和LiveVideoStack年輕的伙伴一起,推動多媒體技術生態發展。同時,也歡迎你利用業余時間、遠程參與內容生產。了解崗位信息請在BOSS直聘上搜索“LiveVideoStack”,或通過微信“Tony_Bao_”與主編包研交流。
總結
以上是生活随笔為你收集整理的8个关于SRT的误区的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 【大会】延迟还能再低点吗?不能,但也能
- 下一篇: 【大会】AI向多媒体各细分场景渗透