こんにちは。
半年ほど前からくしゃみ切り抜きチャンネルで切り抜き動画を投稿させていただいています。
ありがたいことに、コメントをくださる方々や、少し前に始めた切り抜き要望受付で要望を送ってくださる方々がいて、とても励みになっています。
今回は、動画作成の舞台裏を共有することを目的に、主に大変なことや悩みという観点で実情を書こうと思います。
え、こんな記事を書く暇があるなら切り抜き動画を作れって？
まぁまぁ、このくらいは大目に見てください。状況を記録しておくことも大事なことなのです。
大変なこと
まず大変なことについてです。
前提として、この活動をするにあたって切り抜き自動化プログラムを作っているのですが、これを使っても自分の手作業が必要な部分があります。
自分の手作業だけでも、動画時間の約10倍くらいの時間がかかっていると思います。以降で詳しく話します。
切り抜き箇所を決める
まず、自動化プログラムで見つけた切り抜き箇所の候補(くしゃみをしている可能性がある部分)をすべてYouTubeで見て確認することです。
この作業が、手作業全体のほとんどを占めています。
切り抜き箇所の候補は、どの配信者も数百箇所くらいになることが多いです。600箇所を超えてくると絶望感があります。
くしゃみを見られるのに絶望感とは何事かという感じですが、確認作業は単調なので精神的に結構厳しいものがあります。人間なので仕方がありません。
ただ、魅力的なくしゃみであったり、くしゃみに対する反応が面白かったりすると、楽しい気分で作業できます。
これらの候補を確認していく中で、実際に切り抜きに使用する部分を決めます。
決める際には、何秒から何秒まで切り抜くのか、正確に決める必要があります。
この開始終了の時刻指定も結構大変です。
退屈さを軽減するためになるべく不要な部分は入れないようにするのですが、くしゃみの部分だけを切り抜くだけでは不十分です。
というのも、くしゃみ切り抜きは、普段の自然な状態で不意にくしゃみが出るシーンを見られるというのが大きな魅力なので、前後の脈絡を大切にしたいからです。
会話の文脈、くしゃみの予兆、くしゃみ後の反応や鼻啜りなどがなるべく失われないようにしています。
これらを考慮したうえで、何度か巻き戻しながら正確に時刻指定をしています。
幸いなことに、YouTubeには10秒戻しや5秒戻しのショートカット、倍速指定機能があるため、とても確認しやすいです。
こういう細かい点は本当に素晴らしいと思います。YouTubeがここまで台頭するのも納得できます。
上記を考慮すると、1つの箇所につき確認すべきシーンの長さは1分～5分くらいです。
もちろん個人差もあり、くしゃみに対してよく言及する人ほど確認すべきシーンが長くなります。
ここで、最近の例を1つ出してみます。
最近、六道ユラさんのくしゃみ切り抜き動画を公開しました。
動画時間は約3時間20分で、切り抜いた箇所は全部で343箇所でした。(この方はくしゃみの数が多いので動画時間は長めです)
この方は、数十秒おきにくしゃみが出るという連発系の方だったので、それが伝わるようにくしゃみ間の空白の時間も動画に含めるようにしました。(その結果長くなっているのかもしれません)
前後の脈絡を大切にすると書きましたが、これはその一例です。
余談ですが、この方は非常に豪快なくしゃみをするので、最初の方は確認するのが楽しかったのですが、途中から抑えるようになってしまい、正直なところ結構つらかったです。
(残念ながら抑えフェチではありません)
完成動画を確認する
切り抜き箇所を決めたら、あとは動画が完成するまで待ちます。
今の私の環境では動画時間の2倍くらいの時間がかかってしまいますが、待つだけなのでここは妥協しています。
動画が完成したら、あとはアップロードするだけというわけにはいきません。
完成動画が想定通り正しく作られているか確認します。
大抵の場合、指定時刻が1分ずれているなどのミスが数箇所はあるため、動画をすべて確認する必要があります。
最も恐れるべきは人的ミスということです。何事においても同じです。
(加えて、ツール側の問題で映像と音声がずれていることもあるので、確認は必須です)
動画時間が長い場合は特に、この確認作業もかなりの苦痛を伴ってきます。
なぜなら、完成動画には既にYouTubeで確認済みのシーンしか含まれておらず、面白くはないからです。
非常に退屈ですが、この確認作業は先程の切り抜き箇所決定の作業よりは断然楽なので、かなり気楽ではあります。
作業時間も動画時間とほぼ一緒になるので、見通しが立っている点も良いです。
修正点を特定したら、また動画を作り直します。
修正の量が少なければ待ち時間を先程よりも短くすることはできますが、それでも動画時間と同じくらいの時間はかかります。でも待つだけなので気長に待ちます。
完成したら、修正した部分を再度確認し、問題なければアップロードします。
これですぐに動画を公開できると思いきや、そうはいきません。
まず、アップロードに時間がかかります。
例えば先程の六道ユラさんの動画は34GBあります。
mp4という圧縮形式にしてはいるものの、動画時間的にこれくらいのサイズになるのはやむを得ません。むしろ、よくこのサイズで収まっているなという感じです。(配信画面は比較的変化が小さいという要因もあると思いますが)
今の私の環境では、アップロードに動画時間と同じくらいの時間がかかります。回線弱者です…。
さらに、アップロード中はネットワークを圧迫するため、他の通信速度が極端に落ちます。
そのため、長い動画のアップロードは就寝中や外出中などの支障が出ないタイミングで実施するようにしています。
アップロードが完了したら、やっとすぐに動画を公開できると思いきや、そうはいきません。
YouTube側の動画処理が入ります。これはYouTubeで多くの人が快適に流せる形式に変換しているということだと思うので、待つより他はありません。
さらに、問題がないかのチェックが入ります。これは著作権や公的にふさわしくない内容かの確認をしているようです。
これらは合わせて、動画時間の半分くらいから動画時間と同じくらいの時間がかかります。
これらを経て、ようやく公開することができます。
長い動画の場合、完成してから公開するまでに1日程度は空いてしまうんですね。
以上、切り抜き箇所決定と完成動画確認における主に精神的な苦痛を取り上げましたが、この部分は省略できないと思うので諦めて受け入れます。
もちろん、最大限自動化には努めますが。
質を担保する
個人的な思いとして、動画の質は下げたくないと思っています。
今の時代は、TikTokやYouTube Shortsに見られるように、質より量が重視されることは分かっています。
しかし、くしゃみ全集は辞書的に使えるようにもしたいので、質は落とせません。
それゆえ、投稿頻度を現在の週1ペースよりも上げることは難しい気がしています。
要望をたくさんいただいているので早く動画化したいところなのですが、どの配信者もくしゃみ回数が結構多いので短時間での動画化は難しそうです。
切り抜き箇所の確認を妥協したり、切り抜き期間を1年ごとくらいに区切ったりなどすればもっとペースを上げられると思いますが、現状は考えていません。
(要望が多いなら考えます。くしゃみ全集以外のコンテンツがあると良いのかもしれませんが、現状は思いついていないです)
ここは難しいところですが、取り敢えず現在の投稿頻度の背景として、実は上記のような考え方や作業量がありました。
もっと休みが多ければ良いんですけどね…。
休暇が少ないのが日本の特徴なので仕方がありません。でも代わりにVTuberという文化があるので素晴らしい国です。
活動の持続可能性
「持続可能性」という言葉が最近よく使われるようになっていると思うので、何となく使ってみました。「サステナビリティ」というやつです。本当にカタカナ語が好きですよね。
という雑談はさておき、持続可能性というのは、私の状況的にという話ではなく、「YouTubeの規約的に」という話です。
YouTubeの仕様変更が激しい
私が活動を始めてから、YouTubeの規制が厳しくなったことが何度かあったので、まずはそれを簡単に振り返ります。
最初に変化があったのは、2024/07/21-2024/07/24辺りです。
動画データとチャットデータが、ログインなしで取得できなくなりました。
Googleが出している以下の声明の対策結果だと思いますが、これにより作業が少しやりづらくなりました。
Enforcement on Third Party Apps
上記内容を要約すると、「広告なしで見られるアプリを対策する。広告をなくすにはYouTubeプレミアムに加入すれば良い」というものです。
規約違反を対策するのは当然ですが、二次創作を認めているチャンネルの切り抜き動画作成に影響が出るのはとても残念に思います。
と言いつつ、切り抜きという行為自体が著作権的に微妙ではあるので、そもそも切り抜き活動自体が不安定な活動であることは認識しています。それでもくしゃみを切り抜きたいのです。
最近、YouTubeのライブ配信でコメントが表示されなくなる現象が多くのチャンネルで発生していたと思いますが、おそらく先程記載したことが原因です。
OBSというライブ配信ツールの開発者が対応してくれたことで、問題はすぐに解消されたと思いますが。
さて、その後、一度チャットだけはログインしなくても取得できるようになりましたが、結局ログインは必須になりました。
先程からログインが必要と言っていますが、動画の取得にはYouTubeプレミアムのアカウントが必要です。
当然と言えば当然ですが、広告を見ずに動画を取得するからです。
そのため、私は自動化のためにYouTubeプレミアムに加入しています。まぁ元から加入していたので影響はありませんが。
加えて面倒になったのが、動画を連続で取得しようとすると、ボット対策でエラーが発生するようになったことです。
エラーが発生するたびに、いちいち手作業で処理をし直さなければならなくなりました。とても面倒です。
いろいろと書きましたが、現状は切り抜き動画を作成できているので、不満は受け入れられます。
しかし、この状態がいつまで続くかは分かりません。
今後も今回のように、突然仕様変更されることはあるでしょう。
YouTubeがデータ取得を禁止するようになれば、切り抜き動画は作成できなくなります。
私たちは、所詮YouTubeの利用者に過ぎないということです。
今後も自由な活動ができることを、YouTubeには大いに期待しています。
また別の観点として、現状チャットや動画データの取得には、他の人が開発したツールを使用しているため、そこも不安要素になっています。
しかし、データ取得プログラムを自分で開発しようとすると、YouTubeのAPIを理解する必要があり、開発するだけで数ヶ月程度はかかってしまうと思います。
流石に面倒臭すぎるので、問題が発生してから考えようと思います。
問題が発生してから対策を考える、これは誰もが愛する常套手段です。
技術面の悩み
ここからは、少し技術に踏み込んだ話をします。
(特に興味がなければ飛ばしてください)
バックアップを取っていない
普段、データのバックアップはクラウド上にするようにしています。
自身でディスクを管理するよりは信用度が高いからです。
しかし、現在の活動で扱うデータ量は、私用で使うクラウドストレージの容量を大幅に上回っています。
具体的には、活動用に外付けHDDの5TBを2つ使っていますが、例えばGoogleドライブの年契約での最大容量は5TBです。
5TBが年額32000円で、それ以上容量を増やすなら月契約になりますが、30TBだと月額19500円です。
このレベルだと、Amazon S3などのオブジェクトストレージを検討した方が良いかもしれません。
というわけで、クラウドにバックアップを取るのは料金的にも現実的ではないし、必要になった際にダウンロードに時間がかかるという大きなデメリットを抱えているので、基本クラウドは使わないつもりです。
そうすると、自身でディスクのバックアップまたは冗長構成をとる必要が出てきます。
しかし、現状はそこまで考慮できていません。
当然、RAID構成などは取っていません。
これも、どこまでのリスクを考慮するか難しいところです。
そもそもYouTubeからいつでも取得できるデータなのでバックアップの優先度は低いのですが、YouTubeの仕様がいつ変わるか分からないので、そうも言っていられません。
まぁやるとしたらRAID1か定期バックアップくらいですかね。
これにはなるべく早く手を付けたいと思っています。
先程は問題が発生してから対策を考えると書きましたが、この件についてはそういうわけにはいきません。
データを失ったら取り返しがつきませんからね。
取り敢えず、直近でHDD5TBを追加で2つ購入予定です。
最近だと外付けHHDでも5TBの価格が2万円を切って、1万7000円くらいで買えます。ありがたいことです。
なお、長期保存を目的としているので、SSDではなくHDDにしています。
余談ですが、今まで作成した動画については、すべてクラウドにバックアップを取っています。
仮にYouTubeによって動画がすべて削除されてしまったとしても、別の媒体で公開する準備はできています。
処理速度が遅い
前述の通り、動画生成に動画時間の2倍程度の時間がかかっています。
各切り抜き箇所の開始と終了部分に映像と音声のフェード効果を付けているので時間がかかると思いますが、それにしても遅い気がします。
原因はいくつか思い当たるので、そろそろ改善しようかと思っているところです。
具体的には、私は実行環境にWSL(Windows Subsystem for Linux)を使っていますが、通常のLinuxと比べると処理が遅い気がしています。
1つ目の原因として、メモリ使用量の少なさがあると考えています。
本来、WSLはデフォルトでメモリを8GB使うはずなのですが、タスクマネージャーで確認したところ、VmmemWSLプロセスのメモリ使用量は1GB程度でした。
WSLのメモリ上限を手動で16GBに変更しましたが、2GBくらいまでしか増えませんでした。
関連して、自動化プログラムにPythonを使っていますが、動画処理中に勝手にプロセスがKillされたことがありました。
メモリ不足が原因として考えられたため、明示的にガベージコレクションを実施するようにしてこの問題は解決しました。
そういうわけで、WSLにはメモリに関する問題があると思っており、これは処理速度に対してかなり致命的な問題だと認識しています。
因みに、最近Windows11の調子が非常に悪く、アプリが起動しない状態になっています。
ペイントやメモ帳などは起動しませんが、ブラウザやWSL、VSCodeは起動するのが唯一の救いです。
ただ、動画再生アプリが起動しないことで動画の確認が困難になったり、設定アプリが開かずに困ったり、Windowsアップデートに失敗したりと、かなり大きな問題を抱えています。
WSLのメモリの問題もこの現象と何等か関係があるのではないかと思っています。
この件もあり、私用のメインOSをWindowsからUbuntuに変えようか迷っています。こんなことになるとは思っていませんでしたが、今のWindows11では到底信用に値しないと感じます。
2つ目の原因として、ファイルシステムの違いがあると考えています。
WindowsではNTFS、LinuxではXFSやext4というファイルシステムが採用されていて、WSLではこれらのファイルシステムの差異を吸収することができます。
データ量が大きいので、データは外付けHDDに保持していますが、現状はNTFSにしてWindowsからも参照できるようにしています。
しかし、その影響で毎回処理のたびにファイルシステム間の変換が発生しているはずです。
これをLinux側のファイルシステムに統一すれば、かなり処理が速くなると思われます。
ただし、Windowsからは参照できなくなるので、例えば完成動画を確認する際には、毎回Windows側にデータをコピーする必要が出てしまいます。
それほど時間はかかりませんが、少し面倒になります。
この問題も、メインOSをLinuxにすれば解消される話ですが、そのためには既存のデータを移行しなければなりません。
この活動で扱うデータ以外に、普段の私用データもあるので、それらをすべて移行するのかなども含めて今後の運用方法を考えなければならず、結構面倒です。
以上、技術面の悩みについてでした。
切り抜き作業とは別に、システム面でもやるべきことが山積みです。
この活動を通して、ビッグデータを扱うことの大変さをしみじみと感じました。
最後に
切り抜き動画作成における大変なことや悩みについて書きました。
いろいろと面倒なことはありますが、届くべき人のもとへ届けられるように、この活動は長期的に続けるつもりです。
そんな感じで、今後もぼちぼち動画を公開していきます。お楽しみに。
それでは、また。
コメント一覧