中間言語 muml による動画生成 1. プラグインにより拡張可能 2. Web技術ベースの動画編集 3. 動画編集ソフトウェアフレームワーク 1

自己紹介 浅田睦葉 (momeemt) 都立桜修館中等教育学校 6年 Twitter, GitHub: @momeemt 2

目次 ・開発の背景 ・Mockupの提案する編集手法 ・考えられるMockupの応用先 ・フレームに対する処理 ・レンダリング高速化 ・プレビュー ＋ デモ ・苦労したこと ・今後取り組んでいくこと ・mock upによって実現する未来 ・まとめ 3

開発の背景 動画編集は難しい 2020年度 SecHack365 ブロックを用いて編集する 動画編集ソフトウェアを開発 簡単に動画編集ソフトを作りたい 動画編集ソフトを作るのは難しい 2021年度 Mitou Jr 文化祭での動画作成 4

開発の背景 動画編集ソフトウェア開発のタスクを 共通化してフレームワークにしたい！ 動画のデコード/エンコード、図形描画、テキスト描画、座標系の定義、拡大縮小、様々なメディア フォーマットへの対応、トリミング、ネガポジ反転、ゆがみ、ぼかし、アニメーション、部分適用、 3Dオブジェクト、その他フィルター、新しい動画編集ソフトウェアとしての革新的/独自の機能、 レンダリング高速化、プレビュー、スクリプト、プラグイン拡張、音声処理、ソフトウェアとしての設計、 ユーザーインターフェース、ユーザー体験の改善、ユーザーテスト、それらの分析... etc. 5 動画編集ソフトウェア開発を抽象化する

Webベースで動作する動画編集フレームワーク Mockupの提案する編集手法 Web技術ベースでこれらの機能を手軽に利用したい 様々な環境で利用ができる Webサービスの動画編集バックエンド 高性能とも限らないモバイルでの動画編集バックエンド Electron等で動かせばローカルでも利用可能 → UI等はアプリに適したものを開発してもらい、 様々な環境から利用できる拡張可能な動画編集フレームワーク　 6

Mockupの提案する編集手法 → 差分更新については「これから取り組んでいくこと」で再度触れます シンプルなRESTful APIではなく中間言語muml ① 大量のAPIを管理したくない ② 差分の関心を後回しにできる 20種類のフィルターをかけるなら 20個のエンドポイントを叩かなければいけないので辛い 差分更新の実装を後回しにできる 未踏ジュニア期間内では全ての要素を再レンダリングしている 再レンダリング必要なのか そうでないのかが分からない 7

Mockupの提案する編集手法 input output 色反転フィルターをかけるmumlの例 8

Mockupの提案する編集手法 Web開発者 ・UI/UXの改善に取り組む ・mumlを投げるだけ 動画編集機能開発者 ・レンダラを拡張する ・Web APIを意識しないでok mumlによって2種の開発者がシームレスに協業できる 9

Mockupの提案する編集手法 APIも用意されている update preview upload (今後) 動画編集の内容に関係ない部分のみREST API encode mumlを更新する エンコードする プレビューする リソースを追加する 10

Mockupの提案する編集手法 Web API CLIツール 画像 動画 11 類似システムとの比較

Twitter 考えられるMockupの応用先 投稿時に簡単な編集ができる サービスに即した動画編集機能 ▲ 画像をトリミングできる 12

▲ 時刻が連動した動画を流すプロモーションビデオ thechoiceisyours.whatisthematrix.com/jp/ 考えられるMockupの応用先 プログラマブルな動画編集 13 ▲ ゲームの状態を取得して合成する

web 開発者 モバイルアプリ デスクトップアプリ muml フレームを テクスチャに変換 FFmpeg 技術構成 リソース (画像,動画,フォントなど) ... FFmpeg レンダリング テクスチャを取得 フレームに変換 ストリーミングの 初期化・配信 動画ファイルへ 書き出し rtmpサーバー mumlのパース timeline obj生成 必要なシェーダ ファイルの準備 動画像のデコード プレビュー用 ライブストリーム エンコード済み 動画 14

フレームに対する処理 mumlは単なるルールであって、 YAML, JSONなどどんな構造で扱っても良いが、 update APIではJSONとして受け取る ↓ 単にJSONをパースして タイムラインオブジェクトを作成する ① mumlのパース 15

フレームに対する処理 動画像のデコード ② タイムラインが必要な機能を要求する タイムラインオブジェクトから描画に必要な要素を生成する 16 FFmpegの初期化 フォントデータの読み込み FreeTypeの初期化

③ レンダラーがフレームに対して処理を加える フレームに対する処理 17 空のフレームに動画フレームが合成されたり、 フォントデータが合成されることでレンダリングが行われる 図形の描画 テキストの描画 動画像の描画

レンダリング高速化 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 2 3 3 3 3 3 3 4 2 3 3 3 4 4 4 4 CPUに動画を処理させるのは低速 ピクセルは縦 x 横 x 4 (RGBA) 分のデータを持つ 大雑把に言うと1920 x 1080のフレームで、 30fps・1分の動画のピクセルに全てアクセスする場合 1920 x 1080 x 4 x 30 x 60 = 約149億回の計算が必要！ 実際には複数個の素材を重ねるためさらに数倍になる 18

CPU GPU 0 50 100 150 200 250 300 350 レンダリング高速化 現実的な速度でレンダリング可能に 約11.5倍の 高速化 1080 x 720 30fps 30秒程度の動画に 二値化フィルターを掛けてエンコードを行った際の測定結果 ・これまでCPUでは320秒程度かかっていたエンコードが GPUの処理に変更すると25秒程度に改善 ・特にプレビューの実現が現実的になった 19

レンダリング高速化 実装: FFmpegの構造をOpenGLに渡す リソースの準備（動画像のデコード・フォントデータの読み込み）はFFmpegで行う フレーム ピクセルの 色データ テクスチャ 20 シェーダーの適用

プレビューの実装 PREVIEW RTMPサーバー フレームを 送り続ける フレーム 21 (今後) HTTP Live Streaming ブラウザ上で プレビュー

DEMO 22

苦労したこと ・GPUで高速化する必要があったこと ・AVFrameを直接Swscaleにかけると壊れた 　→ フレームは必ず新しく確保し直す ・int, floatでメモリを確保するとメモリ数が環境依 存になり厳密でないのでOpenGLからフレームを読 み出すときに壊れてしまう 　→ 確保するメモリサイズは注意深く確認する これまで苦労したこと これから苦労しそうなこと 23 ・FFmpegのアプリケーションに依存せずフレーム をストリーミングすること ・HTTP Live Streamingへの変換を自前で実装す る必要があること

これから取り組んでいくこと OpenFXへの対応 概要 24 エフェクト・ 合成プラグインの標準 プレビューの利便性向上 差分更新の実装 より高速に レンダリングを行いたい インタラクティブな プレビューの実装

差分更新の実装 ・現在はmumlがupdateされるごとに全てのフレームを再レンダリングしている 　→ 効率が悪い！ ・フレーム規模、レイヤー規模、ピクセル規模と段階的に差分更新を実現していく 　→ 高速化が見込める 25 これから取り組んでいくこと 差分更新

mock upによって実現する未来 ・絵コンテによるモーショングラフィックスの生成 ・声による撮影 + 編集 ・プログラマブルな動画編集のためのドメイン固有言語 ・オブジェクトの関係性に着目した動画編集 新しい編集手法の探究 mock upを用いた開発 ・Webサービスのメディア編集 ・時刻や環境に依存して変化するWebサイト ・動画編集Progressive Web Apps ・複数人編集可能なアプリケーション ニーズに合わせて動画編集ソフトウェアを 開発できる時代が来る 26

まとめ 27 ▲ GitHub ・RESTful APIではなく中間言語で編集することで大量のAPIを管理する必要がなく、 差分更新について後回しにすることができる。出力やストリーミング、アップロード など編集以外の作業と編集そのものを分離できる ・フィルターや図形の描画、アニメーションについて表現でき、これらを組み合わせ ることで複雑な動画を作ることができる ・OpenGLを用いてエンコードを約11.5倍高速化（動画像の構成要素によって変化） ・RTMPサーバーにフレームを送信してプレビューを実装した ・今後はOpenFXへの対応、差分更新の実装、インタラクティブなプレビュー の実装にも取り組んでいく

① フレーム規模 更新がないフレームの 再レンダリングを行わない 差分更新の実装 ・現在はmumlがupdateされるごとに全てのフレームを再レンダリングしている 　→ 効率が悪い！ ・フレーム規模、レイヤー規模、ピクセル規模と段階的に差分更新を実現していく 28 これから取り組んでいくこと 差分更新

① フレーム規模 更新がないフレームの 再レンダリングを行わない ② レイヤー規模 差分が既レンダリング 構成要素より高い要素の 再レンダリングを行わない 差分更新の実装 ・現在はmumlがupdateされるごとに全てのフレームを再レンダリングしている 　→ 効率が悪い！ ・フレーム規模、レイヤー規模、ピクセル規模と段階的に差分更新を実現していく 29 これから取り組んでいくこと 差分更新

① フレーム規模 更新がないフレームの 再レンダリングを行わない ② レイヤー規模 差分が既レンダリング 構成要素より高い要素の 再レンダリングを行わない ③ ピクセル規模 差分のうち既レンダリング要素 より高い構成要素のピクセルは 再レンダリングを行わない 差分更新の実装 ・現在はmumlがupdateされるごとに全てのフレームを再レンダリングしている 　→ 効率が悪い！ ・フレーム規模、レイヤー規模、ピクセル規模と段階的に差分更新を実現していく 差分更新