XNUMX/XNUMX 在 YouTube 上播放您的視頻

最近,作為一種愛好,我一直在拍攝我認識的心理學家的講座。 我編輯影片並將其發佈在我的網站上。 一個月前,我想到在 YouTube 上組織這些講座的 24/7 直播。 致力於個人成長的主題「電視頻道」。

我知道如何進行定期廣播。 但如何使其成為視訊檔案的播放呢? 這樣它就可以 24/7 運行,非常靈活,盡可能自主,同時不以任何方式依賴我的家用電腦。 這就是我必須找出的。

XNUMX/XNUMX 在 YouTube 上播放您的視頻

花了幾天才找到解決辦法。 我研究了很多論壇和各種手冊,沒有它們我的廣播根本就不可能成功。 既然惡作劇成功了,我覺得有必要分享我的解決方案。 這篇文章就是這樣出現的。

簡而言之,最終的解決方案如下: VPS + ffmeg + bash 腳本。 在剪輯下,我描述了所採取的步驟,並討論了在組織廣播時發現的陷阱。

第 1 步 – 廣播從哪裡來?

一開始,需要決定廣播的來源和來源。 我首先想到的是 從您的家用計算機。 將影片收集到播放清單中並開始在任何影片播放器中播放它們。 然後捕獲螢幕影像並將其廣播到 YouTube。 但我幾乎立即拒絕了這個選擇,因為...... 為了實現它,您需要保持家用電腦持續開啟,這意味著即使在夜間冷卻器也會產生噪音,並增加電力消耗(每月+100-150 kWh)。 事實證明,您在廣播期間將無法使用家用計算機。 滑鼠的任何移動都將在廣播中可見。

然後我開始看向旁邊 雲端服務。 我一直在尋找一種現成的服務,可以上傳我的視頻,或者插入 YouTube 視頻的鏈接,然後將其全部打包到一個不間斷的廣播中。 但我沒有找到任何合適的。 可能是我沒搜好。 唯一適合此功能的是 restream.io,這是一項幫助同時向多個平台進行廣播的服務。 他們似乎允許您上傳自己的影片。 但這項服務的創建目的完全不同,他們預計廣播只會持續幾個小時。 我認為,如果透過這項服務可以組織全天候的廣播,那麼每個月的收入將達到數十甚至數百美元。 但我仍然想免費或以最少的資金投入來組織廣播。

很明顯,對於廣播來說,有必要或 單獨的設備 甚至一台單獨的計算機。 我正在考慮像 Raspberri Pi 這樣的東西。 還有什麼? 他沒有冷卻器。 我將視訊錄製在閃存驅動器上,插入乙太網路電纜,並將其放在一個僻靜的地方並進行播放。 選項。 但我既沒有董事會本身,也沒有使用它的經驗,所以我也拒絕了這個選擇。

結果,我遇到了一些討論,他們討論了創作 自己的伺服器 廣播。 這並不完全是我想要的,但我得到了主要想法 - 你可以使用伺服器! 在那次討論中,有人建議使用VPS + nginx + OBS的組合。 很明顯,這種組合也適合我。 唯一讓我困惑的是,我從未管理過伺服器,而且在我看來,擁有自己的專用伺服器既令人困惑又昂貴。 我決定了解租用一台最低配置的伺服器需要多少錢,結果令我驚訝不已。

XNUMX/XNUMX 在 YouTube 上播放您的視頻

價格以白俄羅斯盧布表示,這些只是麵包屑。 要明白,8白俄羅斯盧布大約相當於3.5美元或240俄羅斯盧布。 使用 24/7 開啟並快速上網的功能齊全的計算機一個月。 出於某種原因,這個發現讓我感到非常高興,有幾天我都非常高興地走來走去,就像一個發現了太空火箭的孩子:)

順便說一句,我利用了 Google 提供的第一個網站的優惠來查詢「VPS 租賃」。 也許還有更多的預算解決方案,但這個價格適合我,所以我沒有進一步尋找。

建立伺服器時,您可以選擇它將運行的作業系統。 您可以在任何列出的系統上組織廣播,並根據您的喜好和財務能力做出選擇(對於具有 Windows 的伺服器,他們要求額外付費)。 我選擇了CentOS。 只是因為我以前對此缺乏經驗。

XNUMX/XNUMX 在 YouTube 上播放您的視頻

第 2 步 – 伺服器設置

創建伺服器後您需要做的第一件事是透過 SSH 連接到它。 起初我使用 PuTTy,但後來我開始使用 Secure Shell 應用程序,它在 Google Chrome 中運行。 事實證明這對我來說更方便。

然後我更改了主機名,在伺服器上設定了時間同步,更新了系統,修補了 iptables...並做了很多其他事情,但並不是因為有必要。 我只是對設定伺服器感興趣,它對我有用。 當它成功時我喜歡它:)

以下是您需要採取的步驟:

  1. 連接 EPEL 儲存庫。
  2. 設定FTP伺服器(我選擇vsftp)。
  3. 安裝 ffmpeg。

我不會詳細給出命令;這些指示相當概念性,以便傳達整體行動計劃。 如果您在執行任何步驟時遇到任何困難,可以透過使用搜尋引擎查詢(例如「CentOS connect EPEL」或「CentOS install FTP server」)來快速解決。 在第一個連結上,您可以找到詳細的逐步說明。

因此,正如我之前所寫,我需要 VPS + nginx + OBS 的組合。 VPS-準備好了。 但其他方面開始出現問題。 OBS 是一個廣播程序,即 Open Broadcaster Software。 它僅適用於流,即例如,它從網路攝影機獲取影像並進行廣播。 或螢幕錄製。 或已經正在進行的廣播被重定向到另一個站點。 但我沒有串流,我只有一組需要製作成流的影片檔。

我開始朝這個方向挖掘並遇到了 ffmpeg。 FFmpeg 是一組免費開源程式庫,可讓您以各種格式錄製、轉換和串流數位音訊和視訊。

我非常驚訝 ffmpeg 能做這麼多。 如果需要,它會從影片中提取聲音。 如果需要,它會剪切視訊片段而不重新編碼。 如果需要,它會從一種格式轉換為另一種格式。 還有很多很多。 如果您可以為其指定一個文件,它會將其轉換為串流並將其傳輸到 YouTube 本身。 就這樣,鏈條就組裝好了。 剩下的就是敲定細微差別。

第 3 步 – 廣播設置

我們在 YouTube 上創建了一個廣播。 在這個階段我們只需要連結和廣播金鑰。 在下面的螢幕截圖中,它們以紅色突出顯示。

XNUMX/XNUMX 在 YouTube 上播放您的視頻

進一步 上傳影片檔到伺服器, 我們計劃播出。 實際上,FTP僅在這個階段需要。 如果您有其他方便的方式將檔案上傳到伺服器,那麼您就不必設定 FTP 伺服器。

我們將串流傳輸到 YouTube。 要開始廣播,您需要執行具有多個屬性的 ffmpeg。 這是我得到的最短命令:

ffmpeg -re -i lecture1.mp4 -f flv rtmp://a.rtmp.youtube.com/live2/%КЛЮЧ_ТРАНСЛЯЦИИ%

屬性解碼-re – 表示檔案必須轉換為流。

-i – 指示應播放哪個檔案。 重要的是,該命令是從視訊檔案本身所在的相同目錄啟動的。 否則,您應該指定文件的絕對鏈接,例如 /usr/media/lecture1.mp4.

-f – 設定輸出檔案格式。 就我而言,事實證明 ffmpeg 會即時將我的檔案從 mp4 轉換為 flv。

最後,我們在廣播設定頁面上標明從 YouTube 取得的數據,即您需要將資料傳輸到的位址以及廣播金鑰,以便廣播專門顯示在您的頻道上。

如果您所做的一切正確,那麼在執行此命令後,YouTube 將看到傳輸的串流。 要開始廣播,您只需點擊 YouTube 本身的「開始廣播」按鈕。

步驟 4 – 新增自主權

恭喜! 現在您知道如何從視訊檔案開始廣播。 但這對於 XNUMX/XNUMX 廣播來說還不夠。 重要的是,第一個影片播放完畢後,下一個影片會立即開始,並且當所有影片播放完畢後,會再次開始播放。

我提出了以下選項:建立一個 .sh 文件,在其中為每個視訊文件編寫一個命令,並在最後指示再次運行相同腳本的命令。 結果是這樣的遞歸:

Команда 1... (запуск трансляции файла lecture1.mp4)
Команда 2... (запуск трансляции файла lecture2.mp4)
Команда 3... (запуск трансляции файла lecture3.mp4)
bash start.sh

是的,它確實有效。 我對自己很滿意,開始試播,然後就去睡覺了。

早上,一個令人不愉快的驚喜等著我。 事實證明,廣播只持續了幾分鐘,當我關掉電腦時,廣播幾乎立即結束。 調查顯示,以這種方式啟動的命令是在使用者登入伺服器時執行的。 一旦我斷開連接,我正在運行的命令就會中斷。 為了防止這種情況發生,在團隊面前就足夠了 bash 新增命令 nohup。 這將允許正在運行的進程運行,無論您是否存在。

腳本的最終最小版本如下所示:

ffmpeg -re -i lecture1.mp4 -f flv rtmp://a.rtmp.youtube.com/live2/%КЛЮЧ_ТРАНСЛЯЦИИ%
ffmpeg -re -i lecture2.mp4 -f flv rtmp://a.rtmp.youtube.com/live2/%КЛЮЧ_ТРАНСЛЯЦИИ%
ffmpeg -re -i lecture3.mp4 -f flv rtmp://a.rtmp.youtube.com/live2/%КЛЮЧ_ТРАНСЛЯЦИИ%
nohup bash start.sh $

其中start.sh是編寫此腳本的檔案。 且該檔案必須與視訊檔案位於同一目錄中。

在末尾添加美元符號允許進程在後台運行,這樣您就可以繼續使用控制台而不中斷廣播。

獎金包括以下好東西:

  • 您可以手動切換檔案播放。 為此,您需要「殺死」目前正在運行的 ffmpeg 進程。 此後,將自動開始播放清單中的下一個檔案。
  • 可以在不停止廣播的情況下將新影片新增至廣播。 只需將影片上傳到伺服器,在腳本中新增執行此檔案的命令,然後儲存即可。 就這樣。 下一輪播放時,新檔案將與舊檔案一起播放。

第 5 步 – 自訂 ffmpeg

原則上,我們本來可以就此打住。 但我想讓廣播對觀眾來說更友善一些。

假設一個人去看了廣播,開始觀看,喜歡它並想從頭開始觀看這個講座,但廣播不允許倒帶。 要從頭開始觀看講座,人們需要訪問我的網站並獲取感興趣的講座的錄音。 你怎麼知道他對哪個講座有興趣? 網站上已經有 16 個講座,每週都會有更多講座。 我想,即使是我,拍攝和剪輯了所有這些講座,也無法從隨機的片段中確定這是哪一場講座。 因此,有必要對每次講座進行某種指定。

在編輯程式中為來源視訊檔案新增字幕的選項不適合我。 有必要確保使用原始文件。 所以為了支持轉播,我需要盡可能少的身體動作。

事實證明 ffmpeg 也可以幫助我解決這個問題。 它有一個特殊的屬性 -vf,它允許將文字放置在影片上。 要將文字添加到影片中,您需要將以下片段添加到命令中:

-vf drawtext="fontfile=OpenSans.ttf:text='Лекция 13: Психология эмоций. Как создавать радость?':fontsize=26:fontcolor=white:borderw=1:bordercolor=black:x=40:y=670"

參數說明fontfile= – 字型檔案的連結。 如果沒有這個,標題將不會添加到影片中。 最簡單的方法是將字體檔案與影片放在同一資料夾中。 或者您需要指定文件的完整路徑。

text= – 實際上,文字本身需要放置在影片之上。

fontsize= – 字體大小(以像素為單位)。

fontcolor= - 字體顏色。

borderw= – 文字周圍輪廓的厚度(以像素為單位)(我有白色文本,黑色輪廓為 1 像素厚)。

bordercolor= – 輪廓顏色。

x= и y= – 文字座標。 點 0;0 位於左上角。 我的座標選擇方式是將文字放置在左下角,影片解析度為1280x720像素。

它看起來像這樣:

XNUMX/XNUMX 在 YouTube 上播放您的視頻

第 6 步 – 確定廣播質量

就這樣,廣播準備好了。 FFmpeg廣播,文件播放,廣播不需要我在場。 甚至每堂課都有簽名。 看起來就是這樣。

但又出現了一個細微差別 - 我選擇了最低伺服器配置,但它沒有拉起廣播。 伺服器配置:1 核心(如 2.2 GHz)、1 GB RAM、25 GB SSD。 RAM 足夠,但處理器幾乎完全加載到 100%(有時甚至 102-103% :),這導致每隔幾秒鐘廣播就會凍結。這不太好。

您可以簡單地採用具有兩個核心的更昂貴的配置,幸運的是,利用雲端技術,只需按幾個按鈕即可更改伺服器配置。 但我想適應最低配置容量。 我開始研究 ffmpeg 文檔,是的,那裡還有一些設定可以讓您調節系統上的負載。

高影像品質可以透過兩種方式實現:高 CPU 負載或高傳出流量。 事實證明,處理器可以承擔的負載越大,所需的通道頻寬就越少。 或者你不能給處理器加載太多,但這樣你就需要一個具有大流量餘裕的寬通道。 如果處理器和傳出頻道/流量的大小都受到限制,那麼您將不得不降低影像品質以使廣播順利進行。

我的伺服器可以存取 10 Mbit/s 寬的通道。 這個寬度剛剛好。 但有流量限制 - 每月 1 TB。 因此,為了滿足流量限制,我的傳出流量不應超過每秒約 300 KB,即輸出流的位元率不應超過2,5 Mbit/s。 順便說一下,YouTube 建議以此比特率進行廣播。

為了調節系統負載,ffmpeg 使用不同的方法。 關於這個寫得很好 這裡。 我最終使用了兩個屬性: -crf и -preset.

恆定速率因子 (CRF) – 這是一個係數,您可以透過它調整影像的品質。 CRF可以有從0到51的值,其中0是原始檔的質量,51是最差的質量。 建議使用17到28之間的值,預設為23。係數為17時,影片在視覺上將與原始影片相同,但技術上不會相同。 該文件還指出,最終影片的大小根據指定的 CRF 呈指數變化,即將係數增加 6 個點將使輸出視訊的位元率加倍。

如果使用CRF,您可以選擇傳出圖片的“權重”,然後使用 預設(-預設) 您可以決定處理器的負載量。 此屬性有以下參數:

  • ultrafast
  • superfast
  • veryfast
  • faster
  • fast
  • medium - 預設值
  • slow
  • slower
  • veryslow

指定的參數“越快”,處理器的負載就越高。

我首先選擇了一個對於我的處理器來說基本上太難的預設,然後使用 CRF 更精細地選擇了負載。 就我而言,預設有效 fast,對於 cRF,我選擇了值 24。

結論

就這樣。 啟動廣播的最終命令是這樣的:

ffmpeg -re -i lecture1.mp4 -vf drawtext="fontfile=OpenSans.ttf:text='Лекция 1: Жонглирование картинами мира':fontsize=26:fontcolor=white:borderw=1:bordercolor=black:x=40:y=670" -c:v libx264 -preset fast -crf 24 -g 3 -f flv rtmp://a.rtmp.youtube.com/live2/%КЛЮЧ_ТРАНСЛЯЦИИ%

這裡只剩下兩點沒有描述:

1) -c:v libx264 – 指定用於處理原始檔案的特定編解碼器。
2) -g 3 – 關鍵影格數量的明確指示。 在這種情況下,指定每第三幀應該是關鍵影格。 標準值是 5 或 8,但 YouTube 發誓並要求至少 3。

您可以看到廣播的品質如何 這裡.

伺服器上的負載如下:

XNUMX/XNUMX 在 YouTube 上播放您的視頻

XNUMX/XNUMX 在 YouTube 上播放您的視頻

根據監控數據,可以明顯看出處理器負載在 70% 到 95% 之間,並且在這一周內廣播從未達到 100%。 這意味著有了這些設定處理器就足夠了。

通過加載磁碟,我可以說它幾乎沒有加載,普通硬碟應該足以用於廣播。

但傳出的流量讓我擔心。 事實證明,我的傳出流的速度範圍為每秒 450 到 650 KB。 一個月後,這個數字將達到約 1,8 TB。 您可能需要購買額外的流量或切換到具有兩個核心的配置,因為... 我不想降低圖片品質。

***

因此,我想說,從頭開始設定這樣的廣播大約需要 1-2 小時。 而且,將影片上傳到伺服器會花費大部分時間。

推出這樣的廣播並不能證明自己是一種行銷工具。 也許,如果我們增加觀看次數,以便 YouTube 演算法接收該廣播並開始主動在推薦中顯示它,那麼事情就會成功。 就我而言,連續播放 16 天,觀看次數為 58 次。

那沒問題。 該廣播與我網站的主頁和諧一致。 這讓我有機會快速形成自己對講師和講座本身的看法。

一會兒。 重要的是廣播不能侵犯任何人的版權,否則將會被封鎖。 我對我的廣播很平靜,因為... 我特地選擇了免費使用的音樂插入,內容的作者坐在附近的一台電腦上,並且完全不反對我使用她的內容:)

但是,如果您在廣播中的某處背景中播放收音機,或者您在編輯過程中使用了自己喜歡的曲目,或者從流行音樂視頻、電視劇或電影中截取了視頻序列,那麼您的廣播就會面臨風險。 同樣重要的是,廣播至少攜帶最小的語義負載,否則它可能會被視為垃圾郵件而被阻止。

***

這就是我的全部。 我希望本手冊能夠為某人提供良好的服務。 好吧,如果您有什麼要添加、寫的,我將很樂意閱讀本文的添加和澄清。

來源: www.habr.com

添加評論