Iviストリーミングビデオ準備システム

さまざまな種類のデバイスへのストリーミング用にビデオを準備するには、メタデータの準備から、さまざまなビットレートのさまざまなコンテナ（MP4、DASH、HLS）へのパッキングまで、いくつかの手順を実行する必要があります。 Ivi.ruは、ビデオ制作のスピードにおけるビジネスのニーズを考慮し、5つのDRMシステムで動作できる優先順位を持つ柔軟なシステムを構築しました。 アーキテクチャソリューションは、Dockerコンテナとのジャグリングに基づいており、ビデオをエンコードするためのハードウェアとソフトウェアの両方が含まれています。 ビデオの操作の全体のプロセスとすべての複雑さは、専門家でありiviのテクニカルディレクターであるEvgeny Rossinskyによって詳細に説明されました。 Backend Conf 2017での彼のレポートのカットデコーディングの下。







スピーカーについて

Eugene Rossinsky-2012年から今日まで、CTO iviは働いています。 彼は、Netstreamという非常に負荷の高いプロジェクトの開発で会社を率いました。その成果は、オンライン放送とビデオに関連するプロジェクトでした（smotri.com、ivi）。 2012年以降、Netstreamはチーム全体とともにiviに吸収されました。



2006年以来、彼はMSTUで教えています。 バウマン著者のコース「チーム開発テクノロジー」



今日は、サボテンをかじり、マウスを使って、OnDemandビデオのアップロードを伴うコーディングシステムの作成方法について泣き叫びました。



まず、コンテキストを理解できるように簡単にサービスを紹介し、次に動物に分類されたユーモアとさまざまな詳細に進みます。







それでは、私がお話ししたいこと、つまり著作権所有者からのビデオがエンドユーザーにどのように届くのか、に直接進みましょう。







1.著作権者は、特別なプロトコルを使用してリンクを送信するか（このシステムが自動化されている場合は10％）、元のファイルへのFTPリンクを削除します。



2. Ingestの特別部門（この用語はテレビから取られています）は、コーディングシステムへの送信用にビデオを準備しています。



この作品は何についてですか？ 視聴に適している場合は、著作権所有者が送信したものを確認する必要があります。ビットレートを確認します。このコーデックでは、おそらく最初または最後をカットするコーデックを使用し、サウンドレベルを出力し、色補正などのさまざまな興味深いことを行います。



取り込み部門は2年前に再編成されました。私たち全員がこれを開始し、2種類の専門家を特定しました。

• ビデオコーディングを本当に理解している人々-そして彼らにとって、GOPとキーフレームという言葉は空の文字セットではありません。
  
  
• コーディングシステムと呼ばれるキューシステムオペレーター。 彼らはラムを持っており、それをキューイングシステムに投入します。一方、彼らは2本のソーセージを手に入れます。 スニッフィングソーセージ-通常？ -製品のレイ。
  
  

私たちの仕事は、会社の成長に伴い、ビデオに精通している専門家の数があまり増えないようにすることでした。 「ラムを投げて、2本のソーセージを手に入れる」人の数を増やす必要がありました。



3. Ingestの魔法部門から、ビデオはCoding Systemに入ります 。 これが私たちの遺産であり、これについてお話しします。



4.エンコード後、ビデオはオリジナルサーバーに送られます。



5.次に、標準スキーム-ビデオがCDNにレイアウトされ（マジックを使用するか、単独で）、 エンドユーザーに送信されます。



これは、元のサーバーから始まりCDNで終わる単純な古典的なコンテンツ配布スキームです。



しかし、コーディングシステム自体に興味があります。これについては後で説明しますが、下の質問をします。

私たちの問題は何でしたか

あるいは、2年前に、私たちは何かを変え、世界をより良い場所に、そして悪くないものにする必要があるという結論に達しました。

• コーディング用の実稼働環境を作成する方法について、何キロメートルもの指示がありました。
  
  

ffmpeg、mp4boxなどが大好きです。 開発者：「ああ、新しいバージョン、クラス！ 今すぐ家でそれを集めます！ くそー、ビットレートが5％低下しました！ 一般的に火事だ！ 展開する必要があります！」

そしてここで最もおもしろい部分が始まります-古典的なDevOpsの問題：開発者は1つのインフラストラクチャを持ち、実稼働サーバーには別のインフラストラクチャがあります。 痛みが始まり、ソドミー、うんちを投げ、開発部門と運用部門間の憎しみが始まります。

多くのことを話すことができます-はい、DevOpsなどが必要です。しかし実際はそうではありません-人は常に人であり、お互いを嫌っています。 したがって、まず対立を解消する技術的プラットフォームを提供する必要があります。

• 2番目の大きな問題-コーディングシステムオペレーターの入力レベルの要件を大幅に削減する必要がありました。
  
  

実際に試してみてください-市場でビデオコーディングに精通している人を探してください。約1万単位のコンテンツが提供されているため、さらに多くの人がいます。



たとえば、1年前にインドのシリーズをサンプリングしました。10,000種類をすばやくダンプする必要がありました。 それらはすべて異なるビットレートであり、著作権所有者自身がトレントからダウンロードしたものもあります-完全なソドミー。 そして、これらすべてを何らかの形で処理する必要がありました。



非常に賢明で理解力のある人を必要とするシステムがある場合、10,000のヒントは、品質が正常であるような方法で処理することはできません。 したがって、多くの手順を踏んでいます。

• 次の問題は、ストリーミング用のビデオを準備するために、多くの段階を経る必要があることです。つまり、各段階で失敗する可能性があります-間違いを犯します。
  
  

キューイングシステムに命を吹き込む必要があり、このタスクを再起動するか、修正して再起動するか、「OK、これを原則的にエンコードすることはできません。」

• 次のストーリーはR＆Dです。
  
  

これらは一般に、夜のエリアで目を覚まし、創造的になり始める面白い人です。

「イスラエルのスタートアップがビデオビットレートを10％削減できる新しいコーデックをリリースしました」などの記事がTechCrunchで発表されました 。もちろん、試してみてください！ そして突然判明しました。「それで、私たちはイスラエルのスタートアップと今連絡を取り合っています。g* vnaとsticksからコンセプトを作成しているので、すべてを本番で開始する必要があります！」



そして、別の消費者がフードチェーンに登場するという最初の問題に戻りますが、これは非常に不快です。

• 次は、コンテナ、コーデック、DRMの動物園です。
  
  

実際、コーデックは非常に大きな動物園ではありませんが、コンテナとDRMの使用は非常に巨大です。 私たちは合法的なサービスであるため、単に美しいDashやHLSを受け取って与えることはできません。これを行うことは許可されていないからです。 たとえば、著作権所有者は次のように述べています。「みんな、スターウォーズの映画は、そのようなプラットフォームでのみ、そのようなDRMでのみ提供できます。」



DRMはデジタル著作権管理です。これは、ダウンロードやオーディオおよびビデオコンテンツの盗用を防ぐように思われるものです。 実際、これらのシステムにはいくつかあります。 ほぼすべての一般的なものを実装しています。 しかし、これは痛みと苦痛です。



なんで？ 良い方法では、DRMがどのように機能するかを知ってはいけません-それは保護システムです。 リバースエンジニアリングを行う権利はありませんが、これを行わないと、このナンセンスは機能しません。 したがって、DRMの動作をテストおよびデバッグする方法は、一般的に別の歌です。



その結果、ビデオストリームのエンコードとパケット化の52種類の構成があります。



たとえば、古いLG TVには、HLSの非常に具体的なビューがあります。 彼がすべての基準を満たす正直で、良い、クールなHLSを彼に与えると、彼はそれをプレイすることができませんが、ドックは彼ができると言います。 一般に、彼はMP4以外は再生できません-ユーザーにとっては対応する欠点があります：開始時間、バッファリングなど。



したがって、できるだけ多くのデバイスで再生するために、これらの形式を事前に生成するか、その場で実行するかを学習する必要がありました。 お金はここで決定します-それが私たちにとって利益がある場所とそうでない場所。 これについては少し後で説明します。

• 次の問題-これらのビデオファイルで何ができるのか、何ができないのかをさらに理解するために、エンコードパラメーターの履歴を保存できる必要がありました。
  
  

たとえば、2秒以内にキーフレームを持つすべてのvidosを見つける必要があります。 なぜこれが必要なのか、わかります。



たとえば、チャンク長の変更がCDNの負荷にどの程度影響するか、およびそれがキャッシングアルゴリズムとどのように関連するかをテストする必要があります。 この情報が必要です。 これは重要な話ではなく、それが存在することは不可能ですが、サービスの運用をより費用対効果の高いものにしたい場合に非常に役立ちます。



理解していただくために、当社のコストは、CDNの商用オファーよりも6〜7倍安くなっています。 そのような馬の値札がそこに置かれています。 しかし、これはビジネスであり、通常のマージンを確保する必要があります。 したがって、私たちのコーディングシステムは空のフレーズではありません。

• DevOpsと同様に、テストシステムには大きな問題があります。
  
  

製品に移行する前に機能を最初に監視するのは、QAエンジニアです。 彼は最初にマルチキロメートルの指示を読み、それから彼のクラスターでそれを拾わなければなりません。

一般に、コーディングタスクは多くの時間を必要とするため、最も困難です。 テスターは人間でもあります。彼はエンコードされたものを発売し、お茶を精力的に飲みに行きました。 これで、彼の文脈は失われました。 彼は戻った-すべてが落ちた-それを理解する必要があります。 このような反復は多数あります。

2年前、平均して、1つの新しい機能をテストするのに2週間かかりました。 本当に痛かったです。

同じWebまたはバックエンドで、1日あたり15〜20のリリースをドライブしているという事実にもかかわらず。 これは正常です。



エンコードシステムの場合、ビデオがエンコードされるのを待つのに多くの時間がかかります。 テストファイルの処理は、たとえすべてが黒であっても、シーンの変更はなく、まだ時間がかかります。

• マスカスタマーサービスシステムの一般的な問題。
  
  

コーディングシステムを使用している部門がいくつかあります。 これはコンテンツ部門であり、著作権所有者を排除しますが、「広告」と呼ばれる面白い人がまだいます。

私たちは誇りを持って独立しているので、他の人の薬や針に座らないようにするために、広告のひねりを加えました。 広告主は、この広告素材またはその広告素材をユーザーにすばやく展開できる必要があります。

コーディング演算子とは何ですか？

このような集中モードでは、コーディングを理解している適切な人数の人材を採用できませんでした。



ビジネスは何を望んだのですか？ ビジネスは、同じタイプの日常業務に満足し、喜んでいる安価な専門家を求めていました。



技術部門はコーディングスペシャリストに何を期待しましたか？ スキル：「まあ、写真のようにしてください！」。



私たちは何をするつもりでしたか？

• オペレータ向けの低エントリシステムを作成したかったのです。
  
  
• 必要に応じて接続および切断できる安価でスキルの低い従業員を使用する機会を持つため。
  
  
• 高価な専門家の数を増やさないために、そのような多数の高度な資格を持つ人々の使用はそれほど正当化されません。
  
  

ビデオの準備手順

ステージ＃1

ビデオがシステムに到着すると、まずオリジナルがチェックされます 。ビデオを正しくエンコードする方法を理解しているクールな人でも間違いを犯す可能性があるためです。

• ビットレート
  
  

システムの以前のバージョンの統計によると、たとえば元のビットレートが1 Mbpsだった場合など、非常に頻繁に発生し、エンコードオペレーターは「これからフルHDを作ってください」とシステムに尋ねます。



それは可能です-誰も高級をキャンセルしていません。 システムはこのことを実行します。 出力は次のとおりです。1つの大きな正方形が別の大きな正方形の後に続き、3番目の大きな正方形がすべてを調べます。 ビデオ品質管理エンジニアはこれを見て、「みんな、これはクソだ！」と言います。



ビデオストリーム品質管理の専門家からのn番目のリクエストの後、ビットレートチェックを追加しました。

• 割合。
  
  

私たちの実践では、著作権者が2 x 480のビデオを送信したときに2つの面白いケースがあり、これら2つのストライプが誤ってprodにレイアウトされていました。 実際、これらの2つのストリップの後に、人間の品質管理部門があり、最初の段階では、ビデオストリームが少なくとも何らかの形で9:16または少なくとも3：4に収まるように比率を調べます。 極端な場合、1：20-1：480ではありません。

• FPS
  
  

HPS生成をその場で実験し始めた約6か月前に、FPS（1秒あたりのフレーム-ビデオストリームの1秒あたりのフレーム数）チェックを導入しました。



各チャンクの先頭に常に参照フレームが存在するように、FPS制御が必要です。 チャンクが4秒または2秒で、FPSが断片的である場合、何らかの方法で参照フレームはチャンクの先頭から離れます。



もちろん、カスタマイズしたり、不均等なチャンクを作成したりできます。 ただし、アダプティブストリーミングを行う場合は、何らかの方法で同期する必要があります。 したがって、より単純なルールは、より単純な悪用とそれがすべて機能する方法の理解をもたらします。



コンテンツの7〜10％は部分的なFPSを使用しており、このビデオを任意のコンテナにストリーミングすることはできません。 これで、HLS、DashでMP4をオンザフライでスライスし、すべてをエンコードできるシステムができました。

フラクショナルFPSは悪いです。 なんで？ 別のストリームに切り替えた瞬間に、アダプティブストリーミングが機能し始めるためです。 ユーザーのチャンネルが鈍いので、別のチャンクにすばやく切り替える必要があります。 彼は別のチャンクに切り替えますが、参照フレームはありません。 その後、しばらくの間、ユーザーが画像をバラバラにして黒い画面が表示されます。 それはすべて、コーデックがクライアント側で実装される方法に依存します。

• サウンドトラック。
  
  

多くの場合、ビデオには音声がまったく含まれていないか、音声に別の言語などのラベルが付けられています。

• その他
  
  

ファイルのサイズのチェックを含む、チェックの標準セット。

ステージ＃2

オリジナルが後続の処理に適していると判断した後、ファイル間で目的のビットレートにエンコードされます。 結果のファイルはMP4です。

ステージ＃3

さらに、 パッケージ化と、場合によっては暗号化が実行されます。何らかの理由でビデオストリームをあるコンテナまたは別のコンテナに事前にパックして、後でサーバーから元の静的を送信できるようにする場合。 スタティックは、ロード時に与える方が常に安価ですが、ビットレートの追加コピーを保存する方が高価です。

ステージ＃4-5

その後、オリジナルがサーバーに送信され 、そこで何が起こったかの品質管理に従事している特別に訓練された人々がすでに来ています。

品質管理は2つの部分で構成されています。

• 通常、コンテンツを含むファイルを元のサーバーに持ってきたかどうかを確認する簡単なチェック。
  
  

実際、すべてが正常にコピーされたことを、ストリームからMD5で愚かにチェックします。 約1年に1回、ログに悪い報告があったことのストーリーがあります。つまり、これは発明されたケースではありません。

• さらに、特別に訓練された人は、エンコードされたものが現在の品質と一致するかどうかにかかわらず、ビルトインプレーヤー（最初は管理パネル）の外観を確認します。
  
  

ステージ＃6

その後、私たちはまだ人々からお金を引き出すサービスであるため、このビデオが広告デモのあるモデルで動作する場合、広告を表示したい場所をマークします。

そして、ユーザーにとって良いのは、次のシリーズやその他のことを通知するキャプションラベルです。

ステージ＃7

最後に、特別に訓練された人がスイッチを引くと、コンテンツがエンドユーザーに送られます。バックエンドサーバーは、この特定のビデオストリームへのリンクの配信を開始します。

私たちは何のためにコーディングしていますか？

私たちの最大のクラスターは、ffmpegとさまざまなソフトウェアです。 ハードウェアとソフトウェアの2つのタイプを区別できます。



ffmpegとMP4、HLS、その他のボックスを使用すると、実行するすべてのエンコードタスクの95％が閉じられます。 ただし、1年半前に時間を節約して実験を行うために、エレメンタルからServachoksを購入しました。



これは広告ではなく、彼らは本当に良い人です。 これらのサーバーは、すべての鉄片よりも高価ですが、プラスが1つあります。 ffmpegまたはオープンソースソフトウェアを使用して何かを調理することが難しい場合は、いつでもサポートに連絡して次のように言うことができます。「みんな、スムーズストリーミングはうまくいきません。うまくいきます！」



彼らはあなたにそれを送ります、そして、あなたがそれをスケーリングしたいなら、彼らが送ったものを愚かにコピーして、ソフトウェアソリューションにそれを挿入するか、または「OK、それをElementalで回転させてください」。



現在、実稼働環境ではElementalは1ピースのみに使用されています。 HSSに提供するDRM PlayReadyでコンテンツを作成します。 HSS-これは単なるスムーズストリーミングです-Microsoftがらくたは、それほど多くのデバイスではサポートされていません。 しかし、たとえば、旧式のサムスンやLGのようなフィリップステレビは非常に気に入っています。



他のすべてのプラットフォームはやや速く追いついています。 スマートテレビでは、一般にファームウェアの更新に問題があります。 彼らは非常に頻繁に鉄とすべての両方に古いテリーを投げます。 サポートに問題があります。



しかし、古いモデルで映画を見たい人がいます。私たちの仕事は、ハリネズミと仲良くすることです。



その結果、約95％がソフトウェアコーディングに費やし、5％がElementalを使用したコーディングとパッケージングに費やしています。 R&D, Elemental. - , GPU.



, 4 HDR .

, , , : - , , , ffmpeg, .



:

• API;
  
  
• , ;
  
  
• ;
  
  
• ;
  
  
• .
  
  

- , .

( )

, , .

• Puppet ;
  
  
• Cron, , , ;
  
  
• , , , . , , , , , . すべてが非常に簡単です。
  
  
• Cron' , , . , .
  
  

.

?

:

• : «, ? - ?» MP4.
  
  
• MP4, : «, MP4, . HLS?» , MP4 — MP4 .
  
  

• DASH – HDS.
  
  

, , , .



:

• Ubuntu,
  
  
• ffmpeg,
  
  
• ffprobe,
  
  
• mp4box.
  
  

Django, – Shell- .

– ?

. – - . SSH Elemental , , :

1. ;
   
   
2. .
   
   

– , , .



Elemental: « , ?». , wget' .

, RPC- ( ), .

優先順位

次は？ .



. , . «».







– – . ! , « » – , «», «» - , «».



, , .



- , . なんで？ , , «» – ! KPI « 20 !», : «, , ! 突然！ ! , !».



«»!



? , . , 4 , . . , , .

.

これは何ですか , .



:

• ,
  
  
• ,
  
  
• .
  
  

(catch-forward). – « !? !» ! , . «-6».



, catch-forward catch-up ( ), .



, , . – .



, – , .



, , , .



. 20 , . , , . .



, – , , - . , , , -.







, - , , « , !».



- , , . – .



, , . :

1. Kubernetes , QA- .
   
   
2. .
   
   

. , , «…-, , !». Kubernetes.



, , . , 70% . , , , , , , -.

Docker- – , , .

DevOps-, . Docker- .



Kubernetes . , , , , , , , , , , !



, , Kubernetes, , .



Kubernetes - – , . , , – .



, , Kubernetes. , , , .

?

• -, .
  
  

Docker- – .

• .
  
  

– , , Puppet, .

• .
  
  

Ingest . , , . , , - , , . , , , .



, , , , , , … .

• 
  
  

Elemental , , HLS .

• 2016 (4, 5, 6 – ) .
  
  

CDN, . . !



, , , , - . : ?



, , - , - :



— , – , …

— - ?

— , , .

— , Pb . , , , . ?

— , … , .



, - , , , , .

• QA
  
  

, , , – -. - .



-, – -. – , . . , : «, , ?». ( , ) .

---

,



Backend Conf 2017 HighLoad++ Junior .



++. , .