YouTube でビデオを XNUMX 時間年中無休でブロードキャスト

最近は趣味で、知り合いの心理学者の講義を撮影しています。 映像を編集してホームページに公開しています。 24 か月前、これらの講義を YouTube で 7 時間年中無休で放送するというアイデアを思いつきました。 個人の成長に特化したテーマ別の「テレビ チャンネル」のようなもの。

定期的な放送の作り方を知っています。 しかし、ビデオ ファイルのブロードキャストになるようにするにはどうすればよいでしょうか? そのため、24 時間年中無休で稼働し、柔軟性があり、可能な限り自律的であると同時に、自宅のコンピューターにまったく依存しません。 これが私が調べなければならなかったことでした。

解決策を見つけるまでに数日かかりました。 私は多くのフォーラムやさまざまなマニュアルを研究しましたが、それらがなければ私のブロードキャストは機能しませんでした。 そしていたずらが成功した今、私は自分の解決策を共有する必要があると感じています。 こんな感じでこの記事が登場しました。

要するに、最終的な解決策は次のとおりです。 VPS + ffmeg + bash スクリプト。 カットの下では、実行した手順を説明し、放送を企画する際に発見された落とし穴について話します。

ステップ 1 – ブロードキャストはどこから行われますか?

一番最初に、ブロードキャストの発信元とソースを決定する必要がありました。 一番最初に思い浮かんだのは、 自宅のコンピュータから。 ビデオをプレイリストに集めて、任意のビデオ プレーヤーで再生を開始します。 次に、画面イメージをキャプチャし、YouTube にブロードキャストします。 しかし、私はすぐにこのオプションを拒否しました。なぜなら... これを実装するには、自宅のコンピューターを常にオンにしておく必要があります。これは、夜間でもクーラーから騒音が発生し、電力消費量が増加することを意味します (毎月 +100 ～ 150 kWh)。 そして、放送中は自宅のコンピューターを使用できないことが判明しました。 マウスの動きはブロードキャストに表示されます。

それから私は横を見始めました クラウドサービス。 私は、自分のビデオをアップロードしたり、たとえば YouTube からビデオへのリンクを挿入したり、すべてが XNUMX つのノンストップ ブロードキャストにパッケージ化される既製のサービスを探していました。 しかし、適切なものが見つかりませんでした。 よく検索できなかったのかもしれません。 この機能に適合する唯一のものは、複数のプラットフォームへの同時ブロードキャストを支援するサービスである restream.io です。 自分のビデオをアップロードできるようです。 しかし、このサービスはまったく異なる目的のために作成されたものであり、放送は数時間しか続かないと予想されています。 このサービスを通じて XNUMX 時間放送を行うことができれば、月額数十ドル、場合によっては数百ドルになると思います。 しかし、それでも私は無料か最小限の財政投資で放送を企画したいと考えていました。

放送のためにそれが必要であることが明らかになった、または 別のデバイス または別のコンピューターでも構いません。 Raspberri Piのようなものを考えていました。 そして何？ 彼はクーラーを持っていません。 ビデオをフラッシュ ドライブに録画し、イーサネット ケーブルを接続し、人里離れた場所に置いてブロードキャストしました。 オプション。 しかし、私はボード自体を持っていなかったし、それを扱った経験もなかったので、このオプションも拒否しました。

その結果、あるディスカッションに遭遇しました。 独自のサーバー 放送。 まさに私が探していたものではありませんでしたが、主なアイデアはわかりました - サーバーを使用できるということです。 その議論では、VPS + nginx + OBS を組み合わせて使用​​することが提案されました。 この組み合わせは私にも合うことが明らかになりました。 私を混乱させた唯一の点は、私はサーバーを管理したことがなく、独自の専用サーバーを持つことは混乱を招き、費用がかかるように思えたことでした。 最小構成でサーバーをレンタルするのにどれくらいの費用がかかるかを調べてみたところ、嬉しい驚きを感じました。

価格はベラルーシルーブルで表示されており、これらは単なるパン粉です。 理解すると、8 ベラルーシ ルーブルは約 3.5 ドル、つまり 240 ロシア ルーブルに相当します。 24 時間年中無休で稼働し、高速インターネット アクセスが可能な本格的なコンピューターを 7 か月間使用します。 どういうわけか、この発見は私にとって非常に嬉しくなり、数日間、宇宙ロケットを発見した子供のようにとても幸せそうに歩き回りました:)

ちなみに、私は「VPS レンタル」というクエリに対して Google が最初に提供したサイトのオファーを利用しました。 おそらく、もっと予算の高いソリューションがあるかもしれませんが、この価格が私に適していたので、それ以上は検討しませんでした。

サーバーを作成するときに、サーバーを実行するオペレーティング システムを選択できます。 リストされているシステムのいずれかでブロードキャストを編成し、好みと財務能力に基づいて選択できます (Windows を搭載したサーバーの場合は追加料金がかかります)。 CentOSを選択しました。 単純に、これまでその経験がほとんどなかったからです。

ステップ 2 – サーバーのセットアップ

サーバーを作成した後に最初に必要なのは、SSH 経由でサーバーに接続することです。 最初は PuTTy を使用していましたが、その後、Google Chrome で実行される Secure Shell アプリを使用し始めました。 それは私にとってより便利であることがわかりました。

それから、ホスト名を変更し、サーバー上で時刻同期を設定し、システムを更新し、iptables をいじり...その他たくさんのことを行いましたが、それは必要だったからではありません。 サーバーのセットアップに興味があっただけですが、うまくいきました。 うまくいったときは大好きです:)

実行する必要がある手順は次のとおりです。

1. EPEL リポジトリに接続します。
2. FTP サーバーをセットアップします (私は vsftp を選択しました)。
3. ffmpegをインストールします。

コマンドの詳細については説明しません。これらの指示は、一般的な行動計画を伝えるためにかなり概念的なものです。 いずれかの手順で問題が発生した場合は、「CentOS 接続 EPEL」や「CentOS インストール FTP サーバー」などの検索エンジン クエリを使用すると、すぐに解決できます。 最初のリンクには、詳しい手順が記載されています。

なので、先ほども書きましたが、VPS + nginx + OBS の組み合わせが必要でした。 VPS – 準備完了。 しかし、別の点で疑問が生じ始めました。 OBS は、Open Broadcaster Software という放送プログラムです。 そして、それはストリームでのみ機能します。 たとえば、Web カメラから画像を取得してブロードキャストします。 または画面録画。 または、すでに進行中のブロードキャストが別のサイトにリダイレクトされます。 しかし、ストリームはありません。ストリームに作成する必要がある一連のビデオ ファイルがあるだけです。

私はこの方向に調査を開始し、ffmpeg に出会いました。 FFmpeg は、デジタル オーディオとビデオをさまざまな形式で記録、変換、ストリーミングできるようにする、無料のオープン ソース ライブラリのセットです。

そして、私は ffmpeg がどれだけのことができるかに非常に驚きました。 必要に応じて、ビデオから音声を抽出します。 必要に応じて、再コード化せずにビデオの断片を切り出します。 必要に応じて、ある形式から別の形式に変換します。 そしてそれ以上に。 ファイルを指定できる限り、それをストリームに変換して YouTube 自体に送信します。 これでチェーンが組み立てられました。 あとはニュアンスを最終的に決めるだけです。

ステップ 3 – ブロードキャストのセットアップ

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 をカスタマイズする

原則的には、そこで停止することもできました。 でも、もう少し視聴者に優しい放送にしたいと思いました。

ある人が放送にアクセスして視聴を開始し、気に入ってこの講義を最初から視聴したいと考えましたが、放送では巻き戻しができないとします。 講義を最初から視聴するには、私の Web サイトにアクセスして、興味のある講義の録画を入手する必要があります。 どの講義が彼に興味を持っているかをどのように判断できますか? サイトにはすでに 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 ピクセルでテキストが左下隅に配置されるように選択されています。

次のようになります。

ステップ 6 – ブロードキャストの品質を決定する

以上で、ブロードキャストの準備が整いました。 FFmpeg ブロードキャスト、ファイルの再生、ブロードキャストには私の存在は必要ありません。 すべての講義にもサインが入っています。 それだけのようです。

しかし、もう 1 つのニュアンスが浮上しました。最小のサーバー構成を選択しましたが、ブロードキャストが起動されませんでした。 サーバー構成: 2.2 コア (1 GHz など)、25 GB の RAM、100 GB SSD。 RAM は十分にありましたが、プロセッサはほぼ完全に 102% でロードされていました (時には 103 ～ XNUMX% になることもありました :) これにより、ブロードキャストが数秒ごとにフリーズしました。

単純に XNUMX つのコアを備えたより高価な構成を採用することもできますが、幸いなことに、クラウド テクノロジを使用すると、いくつかのボタンを押すだけでサーバー構成を変更できます。 しかし、最小構成容量に収まるようにしたかったのです。 ffmpeg のドキュメントを勉強し始めました。はい、そこにはシステムの負荷を調整できる設定もあります。

高画質は、CPU 負荷が高いか送信トラフィックが多いかの XNUMX つの方法で実現できます。 プロセッサーが引き受けることができる負荷が大きくなるほど、必要なチャネル帯域幅が少なくなることがわかります。 または、プロセッサに過度の負荷をかけることはできませんが、トラフィックのヘッドルームが大きい幅の広いチャネルが必要になります。 プロセッサと発信チャネル/トラフィックのサイズの両方に制限がある場合、ブロードキャストをスムーズに行うために画質を下げる必要があります。

私のサーバーは 10 Mbit/s 幅のチャネルにアクセスできます。 この幅がちょうどいいです。 ただし、月あたり 1 TB というトラフィック制限があります。 したがって、トラフィック制限を満たすために、送信フローは 300 秒あたり最大 2,5 KB を超えてはなりません。 送信ストリームのビットレートは XNUMX Mbit/s 以下である必要があります。 ちなみに、YouTube はこのビットレートでの放送を推奨しています。

システムの負荷を調整するために、ffmpeg はさまざまなアプローチを使用します。 これについてはよく書かれています ここで。 最終的には XNUMX つの属性を使用することになりました。 -crf и -preset.

定率係数 (CRF) – これは画質を調整できる係数です。 CRF には 0 ～ 51 の値を指定できます。0 はソース ファイルの品質、51 は最悪の品質です。 17 ～ 28 の値を使用することをお勧めします。デフォルトは 23 です。係数が 17 の場合、ビデオは視覚的にはオリジナルと同じになりますが、技術的には同じではありません。 ドキュメントには、指定された CRF に応じて、最終的なビデオのサイズが指数関数的に変化することも記載されています。 係数を 6 ポイント増やすと、送信ビデオのビットレートが XNUMX 倍になります。

CRF を使用している場合は、送信する画像の「​​重み」を選択できます。 プリセット (-preset) プロセッサーの負荷がどの程度になるかを判断できます。 この属性には次のパラメータがあります。

• ultrafast
• superfast
• veryfast
• faster
• fast
• medium – デフォルト値
• slow
• slower
• veryslow

パラメーターを「速く」指定すると、プロセッサーの負荷が高くなります。

まず、基本的にプロセッサーにとって厳しすぎるプリセットを選択し、次に CRF を使用して負荷をより細かく選択しました。 私の場合、プリセットは機能しました fastcrf の場合は値 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/%КЛЮЧ_ТРАНСЛЯЦИИ%

ここでまだ説明されていない点が XNUMX つだけ残っています。

1) -c:v libx264 – ソース ファイルを操作するための特定のコーデックを指定します。
2) -g 3 – キーフレーム数の明示的な表示。 この場合、5 フレームごとにキー フレームになるように指定されています。 標準値は 8 または 3 ですが、YouTube は少なくとも XNUMX を要求しています。

放送の品質がどの程度であるかがわかります ここで.

サーバーの負荷は次のようになりました。

モニタリング データに基づくと、プロセッサの負荷は 70% ～ 95% の範囲にあり、その週のブロードキャストが 100% に達することはなかったことが明らかです。 これは、これらの設定でプロセッサが十分であることを意味します。

ディスクをロードするということは、ほとんどロードされていないと言え、放送には通常の HDD で十分です。

しかし、送信トラフィックの量が気になります。 私の送信ストリームは 450 秒あたり 650 ～ 1,8 KB の範囲であることがわかりました。 XNUMX か月後には約 XNUMX テラバイトになります。 追加のトラフィックを購入するか、XNUMX コアの構成に切り替える必要がある場合があります。理由は次のとおりです。 画質を落としたくありません。

***

結果として、このようなブロードキャストを最初から設定するには約 1 ～ 2 時間かかると言えます。 さらに、ビデオをサーバーにアップロードするのにほとんどの時間がかかります。

このような放送の開始は、マーケティング ツールとして正当化されるものではありませんでした。 おそらく、再生回数を増やして、YouTube のアルゴリズムがこの放送を選択し、おすすめに積極的に表示し始めれば、何かがうまくいくかもしれません。 私の場合、16日間の連続放送で58回視聴されました。

それは大丈夫です。 このブロードキャストは、私の Web サイトのメイン ページに調和して収まります。 これにより、講師や講義自体について自分の意見をすぐに形成する機会が得られました。

そして一瞬。 ブロードキャストが誰かの著作権を侵害していないことが重要です。侵害していない場合、ブロードキャストはブロックされます。 私は自分の放送については落ち着いているので... 私は特に無料で使用できる挿入音楽を選択しました。コンテンツの作成者は近くのコンピューターに座っていて、私が自分のコンテンツを使用することにまったく反対しませんでした:)

ただし、ブロードキャストのどこかでバックグラウンドでラジオが再生されている場合、編集中にお気に入りのトラックを使用した場合、または人気のミュージック ビデオ、テレビ シリーズ、映画からビデオ シーケンスを取り出した場合、ブロードキャストは危険にさらされます。 ブロードキャストが少なくとも最小限のセマンティック負荷を運ぶことも重要です。そうしないと、ブロードキャストはスパムとしてブロックされる可能性があります。

***

それは私が持っているすべてです。 このマニュアルが誰かの役に立つことを願っています。 そうですね、何か追加したいことがあれば、書いてください。記事への追加と説明を喜んで読みます。

出所： habr.com