0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

大容量の動画・音声ファイルを扱うと、なぜ急に作業が面倒になるのか

0
Posted at

動画や音声をAIで文字起こしできるサービスはかなり増えました。

数分程度のMP3や短い動画であれば、ブラウザを開いてファイルをアップロードするだけで処理できるので、Webアプリで特に困ることはありません。

ところが、実際の仕事や学習で扱うデータは、必ずしもそんなに小さくありません。

例えば、長時間のオンライン講義、カンファレンスの録画、インタビュー素材、Podcastの収録データ、ミーティングのアーカイブなど。画質や収録時間によっては、1本の動画が数GBになることもあります。

自分もこうしたファイルを扱うようになってから、

「文字起こし精度よりも、その前のファイル処理の方が大変では?」

と思うことが増えました。

今回は、大容量の動画・音声を扱う時に感じた問題と、最近見直しているデスクトップアプリ中心のワークフローについてまとめてみます。

大容量ファイルでは「アップロードするだけ」が意外と難しい

小さなファイルなら、

ファイルを選択
↓
アップロード
↓
文字起こし
↓
結果を確認

で終わります。

しかし、ファイルサイズが数GBになると話が変わります。

まず気になるのがアップロード時間です。

自宅やオフィスの回線が高速でも、数GBの動画を毎回クラウドへ送信するとなると、それなりに時間がかかります。

さらに厄介なのが、アップロード中の失敗です。

長時間待った後にネットワークが不安定になったり、ブラウザを閉じてしまったりすると、もう一度やり直すことになる場合があります。

1本ならまだ我慢できますが、

lecture_01.mp4
lecture_02.mp4
lecture_03.mp4
lecture_04.mp4
lecture_05.mp4

のように複数の長時間動画を処理したい時は、ファイルを一つずつ操作するだけでもかなり面倒です。

この段階になると、問題は「AIが正確に文字起こしできるか」だけではありません。

大量・大容量のファイルを、どうやって安定して処理するか

というワークフローの問題になってきます。

なぜ動画ファイルは簡単に数GBになるのか

普段YouTubeなどでストリーミング動画を見ていると、動画ファイルそのもののサイズを意識する機会はあまりありません。

しかし、手元にある動画素材は意外と大きいです。

例えば、

  • オンライン講義の録画
  • Zoomなどのミーティング録画
  • 高画質のインタビュー素材
  • カンファレンスの記録映像
  • YouTube編集前の素材
  • 長時間の画面収録

などです。

特に編集前の動画は圧縮されていなかったり、ビットレートが高かったりするため、数時間録画するだけでファイルサイズが大きくなります。

すると、

「内容を文字にしたいだけなのに、まず動画を圧縮しなければならない」

という少し不思議な作業が発生します。

自分も以前は、

大きなMP4
↓
動画を圧縮
↓
必要なら音声だけ抽出
↓
アップロード
↓
文字起こし

という方法を使うことがありました。

もちろん ffmpeg を使えば対応できます。

ただ、文字起こしが目的なのに、その前処理のために毎回コマンドを実行するのは少し面倒です。

ファイルが増えるほど、この「前処理コスト」が無視できなくなります。

大容量ファイルではWebアプリとデスクトップアプリの役割が変わる

以前は、基本的に「WebアプリがあるならWeb版で十分」と考えていました。

インストール不要で、URLを開けばすぐ使えるからです。

今でも、小さなファイルを1〜2本処理するだけならWeb版を選ぶと思います。

一方、大容量ファイルを継続的に扱う場合は、デスクトップアプリにもかなり合理性があります。

例えば最近試しているのが、Video Transcriber AI デスクトップアプリです。

このデスクトップ版では、最大10GBの動画・音声ファイルを扱えるので、大きな録画ファイルを文字起こししたい時に使いやすくなっています。

特に自分が重要だと思ったのは、「10GB対応」という数字そのものより、

文字起こしのためだけに、大容量動画を細かく分割したり圧縮したりする必要を減らせること

です。

ツールの上限に合わせて素材を加工するのではなく、元のファイルをそのままワークフローに入れやすくなります。
image.png

大容量より厄介なのが「大容量 × 複数ファイル」

実際に使っていると、1本10GB近い動画を処理するケースより、

1〜3GB程度のファイルが大量にあるケース

の方が多いかもしれません。

例えば、5日間のオンライン講座を保存した場合、

Day 1:2.4GB
Day 2:3.1GB
Day 3:2.8GB
Day 4:3.5GB
Day 5:2.6GB

ということがあります。

この場合、重要になるのがバッチ処理です。

Video Transcriber AIのデスクトップ版では複数の文字起こしタスクをまとめて処理できるため、ファイルごとに毎回同じ操作を繰り返す必要を減らせます。

例えば夜に複数の講義動画をまとめて追加しておき、処理を進める。

終わったものから文字起こし結果を確認する。

こうすると、「1ファイルずつ待つ」という作業から離れられます。

バックグラウンド処理も地味に重要だった

長時間ファイルでは、処理そのものにも時間がかかります。

その間ずっと同じページを開いて進捗を確認するのは、あまり効率的ではありません。

デスクトップアプリの場合、アップロードや文字起こしタスクをバックグラウンドで継続できるので、別の作業をしながら処理を待てます。

完了後はシステム通知から結果を確認できます。

これは派手な機能ではありませんが、長時間の動画を日常的に扱う場合にはかなり重要でした。

理想的なのは、

ファイルを追加
↓
処理開始
↓
別の作業をする
↓
通知
↓
文字起こし結果を確認

という流れです。

人間がAIの処理を待つのではなく、AIを裏側で動かしておく感覚に近くなります。

文字起こし後に「検索できる」ことにも意味がある

大容量動画を処理する目的は、単に字幕ファイルを作ることだけではありません。

例えば3時間の講義動画を文字起こしした場合、その後に、

「Dockerについて説明していた部分はどこ?」

「この講師がRAGについて話していた箇所だけ読みたい」

といった使い方ができます。

映像のままでは3時間のコンテンツですが、文字起こしすると検索可能な情報になります。

個人的には、大容量動画の文字起こしで一番価値を感じるのはここです。

動画を短くするのではなく、長いままでも扱いやすい情報へ変換する。

長時間コンテンツが増えるほど、この違いは大きくなります。
image.png

Web版とデスクトップ版は用途で分ければいい

実際に使ってみて、Webアプリとデスクトップアプリのどちらか一方が正解というわけではないと感じました。

短い音声を1本だけ文字起こししたいなら、ブラウザを開いてそのまま処理する方が手軽です。

一方、

  • 数GBの動画を扱う
  • 長時間録画が多い
  • 複数ファイルをまとめて処理したい
  • 処理中も別の作業を続けたい

という状況では、デスクトップ版のメリットが大きくなります。

特に「ファイルサイズ」と「ファイル数」が増えてくると、単純な文字起こし性能だけではなく、処理前後を含めたワークフロー全体を見る必要があります。

まとめ

大容量の動画・音声を扱うようになって気付いたのは、

AI処理そのものより、AIに渡すまでの準備がボトルネックになることがある

ということでした。

動画を圧縮して、分割して、一つずつアップロードして、処理が終わるまで待つ。

ファイルが少ないうちは問題ありませんが、容量と本数が増えるほど、この作業は無視できなくなります。

その意味では、最大10GBのファイルに対応し、複数タスクをまとめて処理できるVideo Transcriber AIのデスクトップ版のような選択肢は、大容量コンテンツを扱うワークフローと相性が良いと感じました。

Webアプリが便利になった今でも、デスクトップアプリがなくならない理由の一つは、こういうところにあるのかもしれません。

「Webでできるかどうか」ではなく、

自分が普段扱っているデータ量に対して、どちらの方が作業を減らせるか。

大容量ファイルを扱う時は、この視点でツールを選ぶのが良さそうです。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?