私は通常、次のような状況に陥ります。たとえば、カメラから 650 MB の MPEG-2 .avi ビデオ ファイルがあります。次に、ffmpeg2theoraを使用して、サイズが約 150 MB の Theora .ogv ビデオ ファイルに変換します。最後に、この .ogv ファイルをsshサーバーにアップロードします。
たとえば、ffmpeg2theora私の PC では、エンコード プロセスに 15 分ほどかかります。一方、アップロードは約 60 KB/秒の速度で進行し、約 45 分かかります (150MB .ogv の場合)。したがって、最初にエンコードし、エンコードプロセスが完了するのを待ってからアップロードすると、約時間がかかります
15 min + 45 min = 1 hr
操作を完了します。
ということで、エンコード作業と並行してなんとかアップロードを開始できたらいいなと思いました。次に、原則として - アップロード プロセスは (転送されたバイト/秒に関して) エンコーディング プロセス (生成されたバイト/秒に関して) よりも遅いため、アップロード プロセスは常にエンコーディング プロセスよりも「遅れる」ため、操作全体 (enc+upl) はわずか 45 分で完了します (つまり、アップロード プロセスの時間 +/- ワイヤ上の実際のアップロード速度の状況に応じて数分)。
私の最初のアイデアは、(.ogv のローカル コピーを保持するために) の出力をパイプしてから、次のように - にさらに出力をパイプすることでしffmpeg2theoraた。teessh
./ffmpeg2theora-0.27.linux32.bin -v 8 -a 3 -o /dev/stdout MVI.AVI | tee MVI.ogv | ssh user@ssh.server.com "cat > ~/myvids/MVI.ogv"
このコマンドは確かに機能しますが、ターミナルの実行ログで簡単に確認できますffmpeg2theora。この場合、ffmpeg2theora完了の予測時間は 1 時間と計算されます。つまり、enc+upl の両方の完了時間が短縮されるという点では、メリットがないように思われます。(これはネットワークの輻輳が原因である可能性があり、その時点でネットワーク速度が低下している可能性がありますが、パイプを介して送信されるデータの小さなチャンクごとに確認応答を待つ必要があるように思われます。ffmpeg2theoraその ACK は最終的にどこから来なければなりsshません...そうでなければ、ffmpeg2theora完了時間の見積もりを提供できなかったでしょう。繰り返しになりますが、見積もりが間違っている可能性がありますが、操作は実際には 45 分で完了します。推定で1時間で腹を立てて、Ctrl-Cを押します;）...）
私の2 番目の試みは、1 つの端末ウィンドウでエンコード プロセスを実行することでした。
./ffmpeg2theora-0.27.linux32.bin -v 8 -a 3 MVI.AVI # MVI.ogv is auto name for output
...、および別の端末ウィンドウで を使用したアップロード プロセスscp(これにより、「強制」「並列化」):
scp MVI.ogv user@ssh.server.com:~/myvids/
scpここでの問題は次のとおりです。たとえば、が起動した時点で、ffmpeg2theora既に 5 MB の出力 .ogv ファイルがエンコードされているとしましょう。この時点で、scpこの 5 MB をファイル サイズ全体として認識し、アップロードを開始します。5 MB マークに到達すると終了します。その間に、ffmpeg2theora追加の 15 MB が生成され、.ogv ファイルが終了した時点で合計サイズが 20 MB になる可能性がありますscp(最初の 5 MB の転送が終了します)。
次に、次のように、部分的に完了したアップロードの「再開」をサポートする( joen.dk » Tip: scp Resume ) ことを学びました。rsync
rsync --partial --progress myFile remoteMachine:dirToPutIn/
...、ということrsyncで - の代わりに使ってみたのですが、ファイルサイズに関してはscpまったく同じように動作するようです。つまり、プロセスの最初に読み取ったファイルサイズまでしか転送されず、その後はscp出口。
それで、コミュニティへの私の質問は次のとおりです。総処理時間を短縮するために、エンコードとアップロードのプロセスを並列化する方法はありますか?
次のように、いくつかの方法があると思います。
scpファイルサイズを強制的に/継続的にチェックするコマンドラインオプション（私は見ていません）rsync-ファイルが別のプロセスによって書き込み用に開かれている場合（別のターミナルウィンドウでアップロードを実行するだけです）- bash スクリプト。.ogvファイルが別のプロセスによって書き込みのために開かれている限り実行
rsync --partialされるループで実行すると言います（実行するたびに再開ポイントのハードディスクスキャンを聞くことができるので、実際にはこのソリューションは好きではありません-これ、私は、同じファイルが同時に書き込まれていることがわかっている場合、良いとは言えません)whilersync --partial - 「現在生成されている」/「未完成」ファイルのアップロードをサポートする別のツール (
scp/以外) (増加するファイルのみを処理できるという仮定; ローカルファイルのサイズが突然小さいことに遭遇すると終了します)すでに転送されたバイト)rsync
...しかし、私が何かを見落としている可能性もあります-そして、1時間はそれが得られるのと同じくらい良いです(言い換えれば、並列化しようとしても、合計45分の時間を達成することはおそらく論理的に不可能です) :)
うまくいけば、これを明確にしてくれるコメントを楽しみにしています;）
前もってありがとう、
乾杯！