FFMPEGを使用して、一連の1000枚のPNG画像から非圧縮AVIを作成するにはどうすればよいですか？
このコマンドを使用して、input.aviファイルを一連のPNGフレームに変換しました。
ffmpeg -y -i input.avi -an -vcodec png -s 1024x768 pic%d.png`
次に、これらすべてのPNGフレームから非圧縮AVIビデオを作成する方法を知る必要があります。私はこれを試しました：
ffmpeg -i pic%d.png -y -f avi -b 1150 -s 1024x768 -r 29.97 -g 12 -qmin 3 -qmax 13 -ab 224 -ar 44100 -ac 2 test.avi
しかし、結果のビデオは、元のAVIに比べて多くの品質を失います。
回答:
から「非圧縮」のAVIを取得する方法はいくつかありますが、ffmpeg実際には「ロスレス」を意味すると思われます。どちらの用語も、後で説明するように、定義にかなりのゆらぎがあります。
この議論を、Big Buck Bunnyの 720p HDバージョンでアンカーします。これは、無料で利用可能なビデオであり、すべてテストして比較できる結果を得ることができるからです。24 fpsでの1280 x 720pビデオの生データレートは、29.97 fpsの目標である1024 x 768の目標データレートとほぼ等しいため、私の結果は、映像で期待できるデータレートのかなり良いガイドになるはずです。
次のPOSIXコマンド¹は、以下で説明する内容とほぼ一致するリストを提供します。
$ ffmpeg -codecs 2> /dev/null | grep '^..EV..S ' | grep -vE 'bitmap|image'
自分のマシンでそのコマンドを実行して、FFmpegのビルドがサポートするものを確認したい場合があります。FFmpegは、可能なすべてのエンコーダを有効にして構築されることはほとんどありません。
次に、これらのオプションについて説明します。
「非圧縮」のあなたの定義は、それがデジタル表示により光子になっています前に、映像が右にあるフォームであれば、私が見る最も近いffmpeg -codecsリストがあり-c:v r210、r10k、v410、v308、ayuvとv408。これらはすべて実質的に同じものであり、色深度、色空間、およびアルファチャネルのサポートのみが異なります。
R210および R10Kは、コンポーネントあたり10ビット（ bpc）で4：4：4 RGBであるため、両方とも約、テストでは、 720pで 708 Mbit / sをます。（1時間あたり約TB TBです、友人！）
これらのコーデックはどちらも、2のべき乗サイズが好きなコンピューターによる操作を容易にするために、ピクセルあたり3 x 10ビットの色成分を32ビット値にパックします。これらのコーデックの唯一の違いは、2つの未使用ビットが32ビットワードのどちらの端にあるかです。この些細な違いは、競合企業であるBlackmagic DesignとAJA Video Systemsからそれぞれ由来するため、間違いありません。
これらは簡単なコーデックですが、コンピューターでそれらを使用してファイルを再生するには、おそらくBlackmagicやAJAコーデックをダウンロードする必要があります。両社は、彼らはあなたが顧客によって生成されたファイルを扱うことも知っているので、あなたは、まず自社のハードウェアを購入せずに自分のコーデックをダウンロードできるようになるん彼らのハードウェアのいくつかを持っています。
V410は基本的にR210 / R10KのYUVバージョンです。データレートは同じです。それにもかかわらず、このコーデックはより高速にエンコードする可能性があります。ffmpegます。入力フレームの色空間とこの色空間の間の色空間変換パスが加速される可能性が高いです。
ただし、AJAおよびBlackmagicコーデックがインストールされていても、試したソフトウェアで結果のファイルを再生することができなかったため、このコーデックはお勧めできません。
V308は V410の8 bpcバリアントなので、私のテストでは 518 Mbit / sになります。V410と同様に、これらのファイルを通常のビデオプレーヤーソフトウェアで再生することはできませんでした。
AYUVおよびV408は基本的に同じですが、必要かどうかに関係なくアルファチャネルが含まれています。ビデオが透明度を使用しない場合、これは、上記の10 bpc R210 / R10Kコーデックのサイズのペナルティを、より深い色空間の利点を得ることなく支払うことを意味します。
AYUVには1つの長所があります。それはWindows Mediaの「ネイティブ」コーデックであるため、再生するために特別なソフトウェアを必要としません。
V408は同様にQuickTimeにネイティブであると想定されていますが、V408ファイルはMacのQuickTime 7または10で再生されません。
したがって、PNGに名前が付けられている場合など、これらをすべてまとめると次のようになりますframe0001.png。
$ ffmpeg -i frame%04d.png -c:v r10k output.mov
...or... -c:v r210 output.mov
...or... -c:v v410 output.mov
...or... -c:v v408 output.mov
...or... -c:v v308 output.mov
...or... -c:v ayuv output.avi
AYUVの場合は、Windows専用のコーデックであるため、AVIを指定していることに注意してください。他のコーデックは、お使いのマシンにあるコーデックに応じて、QuickTimeまたはAVIで動作します。一方のコンテナ形式が機能しない場合は、もう一方を試してください。
上記のコマンド（および以下のコマンド）も、入力フレームが既に出力ビデオに必要なサイズと同じサイズであると想定しています。そうでない場合は、-s 1280x720出力ファイル名の前にコマンドのようなものを追加します。
私が疑うように、あなたが実際に「非圧縮」ではなく「ロスレス」を意味する場合、上記のいずれよりもはるかに良い選択は、Apple QuickTime Animationです。-c:v qtrle
AVIが欲しいと言ったのは知っていますが、実際には、ここに記載されているAVIベースのファイル形式のいずれかを読み取るには、おそらくWindowsマシンにコーデックをインストールする必要がありますが、QuickTimeでは、お好みのアプリは、QuickTimeアニメーションファイルを開く方法をすでに知っています。（上記のAYUVコーデックは、私が知っている唯一の例外ですが、そのデータレートは、AVIの利点を得るためだけに非常に高速です。）
ffmpeg詰め込むますqtrleあなたのためのAVIコンテナに、その結果は非常に幅広く対応できない場合があります。私のテストでは、QuickTime Playerはそのようなファイルに少し不満を抱きますが、その後再生します。奇妙なことに、VLCは一部に基づいていますが、VLCはそれを再生しませんffmpeg。このコーデックのQTコンテナーに固執します。
QuickTimeアニメーションコーデックは単純なRLEスキームを使用するため、単純なアニメーションの場合は、以下のHuffyuvと同様に実行する必要があります。各フレームの色が多いほど、上記の完全に非圧縮のオプションのビットレートに近づきます。Big Buck Bunnyでのテストで、RGB 4：4：4モードで165 Mbit / sファイルをを介しffmpegて提供することができました。-pix_fmt rgb24
この形式は圧縮されていますが、PNGの可逆圧縮がピクセル値に影響を与えないのと同じ理由で、PNG入力ファイルに同じ出力ピクセル値を与えます。
ffmpegQuickTimeのアニメーションの実装もサポートし-pix_fmt argbます4取得、：4：4：4 RGB、それはアルファチャンネルを持っているという意味。非常に大雑把に言えば、それは上記のQuickTimeに相当し-c:v ayuvます。ただし、ロスレス圧縮のため、品質や機能を損なうことなくAYUVのデータレートの2分の1未満の214 Mbit / sしか得られません。
ピクセルあたり24ビット未満のQuickTimeアニメーションにはさまざまなバリエーションがありますが、徐々にシンプルなアニメーションスタイルに最適です。ffmpegは、仕様で定義されている他の形式の1つ-pix_fmt rgb555be、つまり15 bppビッグエンディアンRGB のみをサポートしているようです。一部のビデオには耐えられ、ほとんどのスクリーンキャストキャプチャや単純なアニメーションには適しています。色空間の間引きを受け入れることができる場合、122 Mbit / sのデータレートが魅力的であることがわかります。
これをすべてまとめると：
$ ffmpeg -i frame%04d.png -c:v qtrle -pix_fmt rgb24 output.mov
...or... -pix_fmt argb output.mov
...or... -pix_fmt rgb555be output.mov
今、RGBと4：4：4 YUVについてのことは、これらのエンコーディングはコンピュータが処理するのは非常に簡単ですが、人間の視覚に関する事実を無視します。つまり、私たちの目は色の違いよりも白黒の違いに敏感です。
したがって、ビデオの保存および配信システムは、ほとんどの場合、輝度情報よりも色情報の方がピクセルあたりのビット数が少なくなります。これは、クロマサブサンプリングと呼ばれますます。最も一般的なスキームは4：2：0および4：2：2です。
4：2：0 YUVのデータレートは、白黒（Yのみ）非圧縮ビデオの場合よりも50％だけ高く、4：4：4 RGBまたはYUVのデータレートの½です。
4：2：2は、4：2：0と4：4：4の間の一種の中間点です。Y専用ビデオのデータレートの2倍であり、4：4：4のデータレートです。
古いDVカメラ標準のように、4：1：1が表示されることもあります。4：1：1の圧縮されていないデータレートは4：2：0と同じですが、色情報の配置が異なります。
このすべてのポイントは、4：2：0 H.264ファイルで開始する場合、4：4：4非圧縮RGBに再エンコードすると、4：2：0のロスレス圧縮YUVを完全に購入しないということです。ワークフローが4：4：4 RGBであることがわかっていても、これは簡単な変換であるため当てはまります。ビデオハードウェアとソフトウェアは、そのような変換をその場で定期的に行います。
本当に必要なのは、ピクセルを覗いているとき、またはビデオでピクセルレベルの色を変更するときだけで、正確なピクセル値を保持する必要があります。たとえば、4：4：4ピクセル形式では視覚効果（VFX）の作業が簡単になります。そのため、ハイエンドのVFXハウスは、必要な高いデータレートに耐えることができます。
カラーデシメーションを使用してYUVコーデックを開くと、オプションも開きます。ffmpeg多くの事実上ロスレスコーデックがあります。
最も広く互換性のあるオプションはHuffyuvです。これはを介して取得し-c:v huffyuvます。
元のWindows Huffyuvコーデックは、RGB24とYUV 4：2：2の2つのピクセル形式のみをサポートしています。（実際には、YUV 4：2：2の2つのフレーバーをサポートしていますが、ディスク上のバイトの順序のみが異なります。）
FFmpeg Huffyuvコーデックの古いバージョンにはRGB24サポートが含まれていなかったため、試してみてFFmpegがyuv422pピクセル形式を使用する予定であると通知した場合、アップグレードする必要があります。
FFmpegには、YUV 4：2：0をサポートするFFVHuffと呼ばれるHuffyuvバリアントコーデックもあります。この亜種はWindows DirectShow Huffyuvコーデックと互換性がありませんがlibavcodec、VLCなどのに基づいたソフトウェアで開く必要があります。
RGB24 — RGB 4：4：4は、本質的にQuickTime AnimationのRGB24カラースペースオプションと同じものです。2つのコーデックは、特定のファイルの圧縮が多少異なりますが、通常は近いものになります。
また、上記のV308オプションで使用されるYUV 4：4：4モードと本質的に同じです。色空間の変換はリアルタイムで簡単に実行できるため、色空間の違いは実際的な違いはありません。
Huffyuvのロスレス圧縮により、RGB24モードで約251 Mbit / sに圧縮するテストビデオを取得することができました。V308またはAYUVで得られるものと同じ視覚品質です。AVIが絶対に必要な場合、Huffyuvコーデックのインストールは、おそらくAYUVの3倍のデータレートコストを支払うよりも痛みが少ないでしょう。
YUV 4：2：2 —このモードはRGB24よりもビデオにとってはるかに実用的ですffmpeg。開発者が最初にこのモードを選択した理由は間違いありません。上で説明した理論的な⅔の削減から期待するように、テストファイルは173 Mbit / sにエンコードされています。これら2つのテスト間でオーディオトラックが変更されていなかったという事実を考慮すると、それはほぼ正確です。
YUV 4：2：0 —このオプションは、4：2：2よりも色情報を間引き、テストでデータレートを133 Mbit / sに落とします。
これをすべてまとめると：
$ ffmpeg -i frame%04d.png -c:v huffyuv -pix_fmt rgb24 output.avi
...or... -pix_fmt yuv422p output.avi
...or... -c:v ffvhuff -pix_fmt yuv420p output.avi
これffvhuffを書いているときのコーデックのデフォルトは4：2：0であり、実際に使用しているリリースバージョンではそのピクセル形式のみをサポートしていますが、これは変更されているため、このデフォルトが変更された場合にフラグを含める必要があります。
HuffyuvやFFVHuffと同じ精神のより新しいオプションはUt Videoです。Huffyuvのように、Windowsビデオコーデックがあります。つまり、ムービーを再生できるすべてのWindowsプログラムは、コーデックがインストールされたこのコーデックを使用してビデオを再生できます。Huffyuvとは異なり、Macビデオコーデックもあります。そのため、FFmpegベースのソフトウェアやlibavcodecMacでこれらのファイルを読み取ることに制限されません。
このコーデックは色空間に関して非常に柔軟性があるため、一般的な色空間の例をいくつか示します。
4：4：4 RGBを介しては-f avi -c:v utvideo -pix_fmt rgb24得られる178ビット/秒の出力を
4：4：4 YUVを介して-f avi -c:v utvideo -pix_fmt yuv444p得られる153ビット/秒の出力を
4：2：2のYUVを介して-f avi -c:v utvideo -pix_fmt yuv422p得られる123ビット/秒の出力を
4：2：0 YUVを介して-f avi -c:v utvideo -pix_fmt yuv420p得られる100ビット/秒の出力を
ソースビデオが4：2：0 YUVであるため、技術的に同等であるにもかかわらず、このテストでは4：4：4 YUVが4：4：4 RGBよりも優れていると思われるため、YUV形式でデータを配置することにより、より良いロスレス圧縮が可能になります部分的に冗長なUチャネルとVチャネルをファイル内でグループ化することにより。
この分野でのもう1つの興味深いオプションは、FFmpeg独自のFFV1コーデックです。これは主に再生または編集コーデックではなくアーカイブコーデックとして使用されますが、非常に多くのソフトウェアがlibavcodecFFmpegを支えるライブラリに基づいているか、のlibavcodecようなツールを使用してラッシュするffdshowことができるため、とにかく便利です。
デフォルトでffmpegは、FFV1のような柔軟なコーデックを使用する場合、入力ファイルの色空間が保持されるため、4：2：0 YUVを使用する公式のBig Buck Bunny MP4ファイルの1つをフィードすると、それが得られますあなたが与えるない限りアウト-pix_fmtにフラグをffmpeg。これにより、63 Mbit / sの出力ファイルが作成されます。
FFV1にで4：4：4 YUVカラースペースを使用するように強制する-pix_fmt yuv444pと、ファイルサイズは最大86 Mbit / secになりますが、4：2：0のオリジナルからエンコードしているため、この場合は何も購入しません。あなたの代わりにPNG画像のセットに餌場合は、元の質問のように、出力ファイルには、使用する可能性があるbgraかbgr0の単なる再配列されている色空間、argb及びrgb24上記の育てカラースペースを。
別の興味深い代替手段はLossless H.264です。この記事の執筆時点では、これはほとんどx264のみのものですが、エンコード側でFFmpegを使用している人は、VLCなどlibx264、デコード側にも含まれる他のソフトウェアを使用している可能性があります。
このようなファイルを取得する最も簡単な方法は次のとおりです。
$ ffmpeg -i frame%04d.png -c:v libx264 -qp 0 -f mp4 output.mp4
-qp 0フラグがキーです：高い値は、非可逆圧縮を与えます。（-crf 0同じ効果を得るために与えることもできます。）
FFV1と同様にffmpeg、入力色空間から最適な出力色空間を推測しようとするので、上記の結果と比較するために、異なる色空間でBig Buck Bunnyソースファイルで複数のエンコードパスを実行しました。
yuv444p：これはffmpeg、元の質問のようにRGB PNGストリームを与えるときに選択するもので、テストファイルで44 Mbit /秒のファイルになります
yuv422p：これはHuffyuvのデフォルトの色空間に似ていますが、この場合34 Mbit /秒のファイルを取得し、かなり節約できます！
yuv420p：これは、私がテストしているBig Buck Bunny公式MP4のデフォルトであり、結果は29 Mbit /秒のファイルになります。
このような小さなファイルサイズを得るために、多くの互換性を取り合っていることに注意してください。そのため、これをAVIまたはMOVコンテナに詰めようとさえしませんでした。x264と非常に密接に結びついているため、代わりに標準のコンテナタイプ（MP4）を使用することもできます。これにはMatroskaのようなものを使用することもできます。
を追加することで、ビットレートの一部とより速いエンコード時間のトレードオフを実現でき-preset ultrafastます。これにより、テストファイルのビットレートがYUV 4：2：2モードで44 Mbit / sに増加しましたが、約束どおりはるかに高速にエンコードされました。ドキュメント-preset veryslowも価値があると主張していますが、ほんの少しのスペースを節約するだけでエンコード時間はずっと長くなりました。お勧めできません。
ffmpegLagarithのデコード専用モードとLossless JPEGのエンコード専用モードもサポートしています。これらの2つのコーデックは実際には多少類似しており、同じ品質のファイルをHuffyuvよりも少し小さくする必要があります。ffmpeg開発者がLagarithエンコーディングを追加した場合、Huffyuvの強力な代替手段になります。ただし、ロスレスJPEGをお勧めすることはできません。これは、幅広いデコードサポートを享受できないためです。
次に、知覚的にロスレスなコーデックがあります。ピクセルのぞき見をしているのでない限り、これらが前の2つのグループとは異なる視覚的結果をもたらすことをほぼ確実に知ることはできません。ビデオキャプチャセンサーとディスプレイデバイス間の変更を絶対にゼロにするという考えをあきらめることで、大幅な節約を購入できます。
Apple ProRes：-c:v proresまたは-c:v prores_ks— ProResはプロファイルベースのコーデックです。つまり、品質とスペースのトレードオフがそれぞれ異なる複数のバリアントがあります。
ProRes 4444は、わずか 114 Mbit / sを使用してテストビデオをエンコードしますが、 VFX品質です。現在prores*、FFmpegには3つの異なるコーデックがありますが、prores_ksProRes 4444のみをサポートしてい-profile:v 4444ます。
ロスレスH.264を介してProRes 4444を使用する理由がわからない場合は、互換性、デコード速度、予測可能性、およびアルファチャネルに依存します。
ProRes 422はさらにスペースを節約し、 84 Mbit / sで ProRes 4444からピクセルの覗き見で結果を得ることができます。ProRes 4444が提供するアルファチャネルが必要でない限り、おそらくProRes 4444を主張する理由はありません。
ProRes 422は、どちらもアルファチャネルをサポートしていないため、上記のLossless H.264オプションに近い競合製品です。Appleプロビデオアプリとの互換性、エンコードとデコードのCPUオーバーヘッドの削減、または予測可能なビットレートが必要な場合は、ProResの高いビットレートを許容する必要があります。後者は、ハードウェアエンコーダーなどで重要です。一方、Lossless H.264の互換性の問題に対処できる場合は、4：2：0色空間を使用するオプションがありますが、これはどのProResプロファイルのオプションでもありません。
FFmpegの3つのProResエンコーダーはすべてProRes 422プロファイルをサポートしているため、最も簡単なオプションは-c:v prores、ではなくを使用する-c:v prores_ks -profile hqか、自動プロファイル機能に依存prores_ksして正しいことを行うことです。
さらに控えめなProResプロファイルがありますが、それらはSDビデオ用またはフル解像度ファイルのプロキシ用です。
ProResの主な問題は、Appleおよびプロビデオの世界以外ではまだ広くサポートされていないことです。
AvidのDNxHDはProResと同様のコーデックですが、Appleプロビデオの世界とは関係ありません。Avidは、WindowsとMacintoshの両方に無料でダウンロード可能なコーデックを提供し、FFmpegはを介してサポートしてい-c:v dnxhdます。
DNxHDはProResのようなプロファイルベースのコーデックであるため、定義済みのセットからプロファイルを選択し、使用するフレームサイズ、フレームレート、ビットレートをコーデックに伝えます。Big Buck Bunnyテストファイルの場合、-b:v 60Mプロファイルが最も適切です。当然のことながら、結果のファイルは約59 Mbit / sです。
低損失MJPEG：-vcodec mjpeg -qscale:v 1—これは、ロスレスJPEGよりもはるかに一般的です。実際、これはかつて非常に一般的なビデオ編集コーデックでしたが、依然としてネットワークストリーミングビデオカメラなどで頻繁に使用されています。すべての歴史は、それをサポートするソフトウェアを簡単に見つけることができることを意味します。
このコーデックからのデータレートのかなり広い変動性を期待してください。ここで行ったテストでは、720pビデオで25 Mbit / sが得られました。これは圧縮性が高いため、損失を心配することはできますが、かなり良さそうに見えました。データレートだけに基づいて、おそらく12メガビット/秒の MPEG-2または6メガビット/秒の H.264と同等の品質であると思います。
これをすべてまとめると：
$ ffmpeg -i frame%04d.png -c:v prores_ks -profile:v 4444 output.mov
...or... -c:v prores_ks -profile:v hq output.mov
...or... -c:v prores output.mov
...or... -c:v dnxhd -b:v 60M output.mov
...or... -c:v mjpeg -qscale:v 1 output.avi
これらの方法の一番下の行は、あなたが非常に要求の厳しい何かをしていない限り、「十分」は本当に十分であるということです。
脚注と余談
このコマンドは、Linux、macOS、BSD、およびUnixでそのまま動作するはずです。Windowsを使用している場合は、CygwinまたはWSLを介してPOSIXコマンドラインを取得できます。
そのコマンドによって作成されたリストが、上で説明するために選択したコーデックのセットと完全に一致しない理由はいくつかあります。
2番目grepは、このリストbmpでタグ付けさVれているにもかかわらず、「ビデオ」コーデックではない不適切なエンコーダを除外するためのものです。技術的には、おそらくこれらの多くをAVI、MP4、またはMKVなどのコンテナーに詰めて単一ファイルのビデオを取得できますが、そのファイルは、ffmpegまたはに基づくプログラム以外では読み込めませんlibavcodec。
これにはいくつかの例外があります。たとえば、-f avi -c:v ljpeg「Lossless MJPEG」と呼ばれるものがありますが、原則として、多くの静止画像ファイルをここのA / Vコンテナに詰めてムービーを作成することは考えていません。ここでは、セマンティックトリックではなく、広く認識されているビデオコーデックが必要です。
現在、コマンドは、GIFなどの一部の不適切なエンコーダーをフィルターに掛けることができません。これらのエンコーダーは、ffmpeg -codecs出力bitmapまたはimageファイル形式として現在記述されていないためです。
GIFは興味深いケースです。モーション再生のタイミング情報を含む単一のGIFファイルで複数の画像フレームをサポートしますが、いくつかの理由から、ここでの議論にはまったく不適切です。
示されたオプションのいくつかは、廃止されたり、本当にのような多くのトラクションを、やったことがなかったflashsv、diracと、snowそれは上にそれらを議論する価値はありませんので、。
そのリストのオプションの一部は、ffmpegインスタンス間またはffmpeg別のプログラム間のパイプラインで使用するためのものでrawvideoありwrapped_avframe、and など、ここでの目的には不適切です。
上記の説明の終わり近くで、慎重に選択したいくつかの不可逆オプションを含めるように質問の範囲を少し慎重に拡大grepし、上記のコマンドの最初のフィルターを渡さないようにします。
だから、私は自分の答えを長すぎてしまった。
TL; DRサマリー：画像のシーケンスをロスレスに保存するには、libx264またはlibx264rgbを使用し-preset ultrafast -qp 0ます。ffvhuffとほぼ同じ速度で、ビットレートははるかに低く、デコードも高速です。 huffyuvはffmpegの外部でより広くサポートされていますが、ほど多くのピクセル形式をサポートしていませんffvhuff。したがって、これは、他のツールがHigh 4:4:4 Predictivex264がロスレスモードで使用するh.264 プロファイルを処理できると仮定して、h.264を使用するもう1つの理由です。x264は、任意のフレームへの高速ランダムアクセスが必要な場合にイントラのみを実行できます。
イメージのディレクトリから読み込むときに、libx264rgbに影響するffmpegのバグに注意してください。（そして、誰が他のどのようなケースを知っているか。）使用する前に、セットアップのロスレスをテストしてください。（ffmpeg -i in -pix_fmt rgb24 -f framemd5オンソースで簡単、ロスレス圧縮））
編集：utvideoエンコードとデコードはかなり高速で、h.264よりもはるかに簡単なコーデックです。基本的にはhuffyuv、より便利な色空間のサポートを備えたモダンです。h.264で問題が発生した場合は、一時ファイルについてutvideo nextを試してください。
edit2：RGBコーデックとしてのPNGは、少なくともSintel予告編ではうまくいくようです。
同様の質問に対する私の同様の回答も参照してください：https : //superuser.com/a/860335/20798
Warren Youngのさまざまな生のフォーマットとコーデックに関する回答には多くの情報があります。答えが短いとより便利だと思うので、新しい答えを作っています。ロスレスx264またはffvhuffをサポートしていないソフトウェアを使用している場合、その情報の一部はおそらく有用です。
このコンテキストでの「ロスレス」の最も便利な定義は、ビット単位で入力を回復できることです。何をするかに関係なく、ビデオエンコーディングの品質が低下する心配はありません。
http://en.wikipedia.org/wiki/Chroma_subsampling
理想的には、複数の色空間変換を避ける。丸め誤差は蓄積される可能性があります。RGBカラースペースで機能するフィルターを使用してビデオを操作する場合、高ビットレートが問題にならない限り、RGBを維持することは理にかなっています。おそらく最終的にはyuv 4:2:0ビデオを作成することになるでしょうが、適用するフィルターによっては、追加のクロマ解像度を維持することが潜在的に有用です。
いずれかの方法で、ロスレスx264の、サポートRGBとYUVの両方ffvhuff 4:4:4、4:2:2と4:2:0。デコードが速いので、x264をお勧めします。RGB HDビデオをリアルタイムで再生しようとしている場合、xvではなくopenglを試してください。私のシステムのxvはyuv入力のみを受け入れるためです。mplayerは、色空間の変換に余分なCPU時間を使用していました。
以下のエンコーダ・テスト用のソース：https://media.xiph.org/。 https://media.xiph.org/sintel/sintel_trailer-1080-png.tar.gz 彼らはsintelトレーラー用のy4mファイルをgzipするのを忘れていたため、png tarballは実際にはずっと小さくなっています。
ffmpeg -i 1080/sintel_trailer_2k_%4d.png -i sintel_trailer-audio.flac \
-c:a copy -c:v libx264rgb -preset ultrafast -qp 0 \
frompng.sintel.264rgb.mkv
例えば
peter@tesla:/mnt/GP1TB/p/encoder-sample/sintel$ time ffmpeg -i 1080/sintel_trailer_2k_%4d.png -i sintel_trailer-audio.flac -c:a copy -c:v libx264rgb -preset ultrafast -qp 0 frompng.sintel.264rgb.mkv
ffmpeg version N-67983-g2b358b4 Copyright (c) 2000-2015 the FFmpeg developers
built on Jan 10 2015 05:32:37 with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1)
configuration: --enable-gpl --enable-version3 --enable-nonfree --disable-doc --disable-ffserver --enable-libx264 --enable-libx265 --enable-libmp3lame --enable-libopus --enable-libwebp --enable-libvpx --disable-outdev=oss --disable-indev=oss --disable-encoder=vorbis --enable-libvorbis --enable-libfdk-aac --disable-encoder=aac --disable-decoder=jpeg2000
libavutil 54. 16.100 / 54. 16.100
libavcodec 56. 20.100 / 56. 20.100
libavformat 56. 18.100 / 56. 18.100
libavdevice 56. 3.100 / 56. 3.100
libavfilter 5. 7.100 / 5. 7.100
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 3.100 / 53. 3.100
Input #0, image2, from '1080/sintel_trailer_2k_%4d.png':
Duration: 00:00:50.12, start: 0.000000, bitrate: N/A
Stream #0:0: Video: png, rgb24, 1920x1080 [SAR 72:72 DAR 16:9], 25 fps, 25 tbr, 25 tbn, 25 tbc
Input #1, flac, from 'sintel_trailer-audio.flac':
Duration: 00:00:52.00, start: 0.000000, bitrate: 721 kb/s
Stream #1:0: Audio: flac, 48000 Hz, stereo, s16
File 'frompng.sintel.264rgb.mkv' already exists. Overwrite ? [y/N] y
No pixel format specified, rgb24 for H.264 encoding chosen.
Use -pix_fmt yuv420p for compatibility with outdated media players.
[libx264rgb @ 0x2770760] using SAR=1/1
[libx264rgb @ 0x2770760] using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle
[libx264rgb @ 0x2770760] profile High 4:4:4 Predictive, level 4.0, 4:4:4 8-bit
[libx264rgb @ 0x2770760] 264 - core 144 r2525+2 6a4fca8 - H.264/MPEG-4 AVC codec - Copyleft 2003-2014 - http://www.videolan.org/x264.html - options: cabac=0 ref=1 deblock=0:0:0 analyse=0:0 me=dia subme=0 psy=0 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=0 chroma_qp_offset=0 threads=3 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=0 weightp=0 keyint=250 keyint_min=25 scenecut=0 intra_refresh=0 rc=cqp mbtree=0 qp=0
Output #0, matroska, to 'frompng.sintel.264rgb.mkv':
Metadata:
encoder : Lavf56.18.100
Stream #0:0: Video: h264 (libx264rgb) (H264 / 0x34363248), rgb24, 1920x1080 [SAR 72:72 DAR 16:9], q=-1--1, 25 fps, 1k tbn, 25 tbc
Metadata:
encoder : Lavc56.20.100 libx264rgb
Stream #0:1: Audio: flac ([172][241][0][0] / 0xF1AC), 48000 Hz, stereo (16 bit)
Stream mapping:
Stream #0:0 -> #0:0 (png (native) -> h264 (libx264rgb))
Stream #1:0 -> #0:1 (copy)
Press [q] to stop, [?] for help
frame= 1253 fps= 18 q=-1.0 Lsize= 834790kB time=00:00:51.96 bitrate=131592.5kbits/s
video:830198kB audio:4575kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.002025%
[libx264rgb @ 0x2770760] frame I:6 Avg QP: 0.00 size:612470
[libx264rgb @ 0x2770760] frame P:1247 Avg QP: 0.00 size:678787
[libx264rgb @ 0x2770760] mb I I16..4: 100.0% 0.0% 0.0%
[libx264rgb @ 0x2770760] mb P I16..4: 50.3% 0.0% 0.0% P16..4: 12.0% 0.0% 0.0% 0.0% 0.0% skip:37.6%
[libx264rgb @ 0x2770760] coded y,u,v intra: 71.1% 68.2% 70.0% inter: 22.8% 22.8% 23.2%
[libx264rgb @ 0x2770760] i16 v,h,dc,p: 50% 48% 1% 1%
[libx264rgb @ 0x2770760] kb/s:135693.94
-r 24fps を指定するのを忘れたため、オーディオとのv同期が維持されないことに注意してください。（およびビットレート（ファイルサイズではありません）の数値もオフになります。ffmpegのデフォルトは25fpsです）。このマシンのCPUは、第1世代（conroe）core2duo 2.4GHz（E6600）です。
結果：
4.5M sintel_trailer-audio.flac # this is muxed in to every mkv
948M 1080 # the directory of PNGs
940M /var/tmp/dl/sintel_trailer-1080-png.tar.gz
7434M sintel.y4m # yuv444, uncompressed. mplayer gets the colors wrong?
2342M qtrle.mkv # encode went at 16fps, so qtrle is slower and worse filesize
2105M sintel.huff.mkv # ffvhuff with default options, rgb pix fmt
1228M sintel.utvideo.mkv # muxed without audio, I should update the others this way
946M png-copy.mkv # -codec copy makes a MPNG stream. Use -codec png for non-png sources, but it won't make PNGs as small. Decodes very fast
824M lossy.prores_ks.mov # yuv444p10le extremely slow to encode (2.3fps), and worse bitrate.
816M frompng.sintel.264rgb.mkv
735M sintel.x264rgb.medium.nocabac.mkv # encode went at 3.3 fps instead of 18. Better gain than for live-action, though
626M sintel_trailer.rgb.lossless.veryslow.mkv # 1.1fps. With CABAC, 16 ref frames, etc. etc.
512M lossy.prores.mov # yuv422p10le, 12fps
341M sintel.yuv420.x264.lossless.mkv
21M lossy.rgb.crf26.preset=medium.mkv
13M lossy.yuv420.crf26.preset=medium.mkv # remember this is WITH 4.5MB audio
mediainfoRGB h.264を知らないことに注意してください、それでもファイルがYUVであると言います。
本当にロスレスであることを確認してください：
ffmpeg -i 1080/sintel_trailer_2k_%4d.png -f framemd5 png.framemd5
ffmpeg -i fromhuff.sintel.264rgb.mkv -an -sn -pix_fmt rgb24 -f framemd5 x264rgb.framemd5
diff -s *.framemd5
Files png.framemd5 and x264rgb.framemd5 are identical
そのため、元のPNG入力をそのように復元できます。つまり、同一の画像データを含むPNGを作成できます。
-pix_fmt rgb24x264テストに注意してください。ffmpegのh.264デコーダーはgbrp（平面、パックではない）出力を出力するため、ビットは同じですが、順序は異なります。framemd5の「コンテナ」は、何らかの形式の制限を課しませんが、ビットが同じように配置されている場合にのみ同じmd5を取得します。私はffmpegがPNGをフィードするときにpix fmtに使用していることを見て、それ-pix_fmtをデコードの引数として使用しました。ちなみに、これがvlcがRGB h.264ファイルを再生しない理由です（次のリリースまで、または現在のナイトリービルドまで）：gbrpピクセル形式をサポートしていません。
yuvの使用libx264ではなくlibx264rgb。x264のRGBバージョンをインストールする必要はありません。実際のライブラリは両方をサポートしています。2つの異なる名前のエンコーダーとして実装したのは、ffmpegだけです。彼らがそうしなかった場合、デフォルトの動作は、rgb入力をrgbのままにして、同じ品質ではるかに高いビットレート出力を生成しながら、本当にゆっくり実行することだと思います。（必要に-pix_fmt yuv420p応じて420、444h.264出力の代わりに使用する必要がある場合があります。
長期保存用のファイルを作成する場合-preset ultrafastを除き、常にロスレスx264に使用してください。参照フレームとモーション検索を増やしても、ロスのない、アニメーションのないノイズのある素材ではほとんど違いがありません。CABACは、デコードにも、ロスレスビットレートで大量のCPUを使用します。スクラッチファイルではなく、アーカイブ目的でのみ使用します。（ultrafastはCABACを無効にします）。CABACは、ビットレートを10〜15％節約します。
すべてのフレームをキーフレームにする必要がある場合は、を設定し-keyint 1ます。次に、キーフレームまたはw / eのみをカットしたいビデオ編集ソフトウェアは、あなたを制限しません。
元の質問に答えるには：これは、段階的に物事を試みている間に一時ファイルを回すためにすべきことです（例：遅いインターレース解除、他の物事を試みる前にロスレス出力を保存する）：
ffmpeg -i dv-video-source.ts -vf yadif=2:1,mcdeint=3:1:10 -c:a copy -c:v libx264 -preset ultrafast -qp 0 deinterlaced.mkv
静止画像ツールで変更できる画像ファイルの出力が本当に必要な場合は、必ずpngにデコードしてください。各ピクセルのY、Cb、Crの各値の8ビットの最下位ビットよりも多くのものを失うことはありません。
これはx264が本当にうまく機能する理由は、テキストが少し入った多くの黒いフレーム、フェードインとフェードアウト、および多くのフレームの大きな領域間の完全な類似性があるため-preset ultrafastです。実写では、まだffvhuff（yuv420）の半分のファイルサイズでx264が表示されます。
好奇心anyone盛な人向け：高CPU時間ロスレスrgbエンコードには（x264コア144 r2525）がありました：
[libx264rgb @ 0x35b97a0] frame I:27 Avg QP: 0.00 size:604367
[libx264rgb @ 0x35b97a0] frame P:1226 Avg QP: 0.00 size:517512
[libx264rgb @ 0x35b97a0] mb I I16..4..PCM: 46.3% 38.1% 15.7% 0.0%
[libx264rgb @ 0x35b97a0] mb P I16..4..PCM: 24.3% 5.4% 4.5% 0.0% P16..4: 10.5% 3.3% 5.7% 0.0% 0.0% skip:46.3%
[libx264rgb @ 0x35b97a0] 8x8 transform intra:17.3% inter:46.1%
[libx264rgb @ 0x35b97a0] coded y,u,v intra: 81.6% 77.5% 80.0% inter: 28.0% 27.7% 28.1%
[libx264rgb @ 0x35b97a0] i16 v,h,dc,p: 35% 64% 1% 0%
[libx264rgb @ 0x35b97a0] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 31% 49% 13% 2% 1% 1% 1% 1% 1%
[libx264rgb @ 0x35b97a0] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 31% 37% 5% 5% 6% 5% 5% 4% 3%
[libx264rgb @ 0x35b97a0] Weighted P-Frames: Y:41.1% UV:40.7%
[libx264rgb @ 0x35b97a0] ref P L0: 74.5% 4.2% 9.1% 4.1% 2.1% 1.7% 1.2% 0.8% 0.6% 0.5% 0.3% 0.2% 0.2% 0.2% 0.2% 0.1%
[libx264rgb @ 0x35b97a0] kb/s:99721.66
加重pフレームの非常に高い割合、およびスキップマクロブロックの非常に高い割合に注意してください。すべてのシーンのトランジションはカットではなくフェードであり、x264にCPU時間を与えて方法を把握すれば利用できます。
クリップを介して前方/後方にスクラブするには、通常、イントラのみのコーデックが適しています（utvideo、ffvhuff、mjpeg、jpeg2000、pro-res、AVC-Intra）。短いGOP（1/2〜1秒）の通常のAVCも、ソフトウェアが何をしているのかを知っていれば（スクラブ時に最も近いIフレームをデコードし、GOP内でデコードして、必要に応じてタイムラインで十分にズームインしている場合はインターフレーム）。
これとhttps://video.stackexchange.com/に、「ロスレスコーデックよりも圧縮速度が遅く、品質が悪い場合のポイント」など、pro-resについて否定的なことを投稿しましたが、いくつかの興味深い機能があります。 Appleは、フルレゾのデコードのCPU時間のわずか1/3を使用して、ハーフ解像度でデコードできると述べています。
ffmpegのprores実装は、おそらくAppleの場合ほど速度が最適化されていないため、ffmpegでテストした結果、速度が遅くなりました。ffmpegに基づくツールを使用したフリーソフトウェアワークフローがある場合は、おそらく使用する価値はありませんが、商用ソフトウェアを使用している場合は試してみる価値があります。
私は多くのビデオ編集をしていません。ほとんどはエンコードだけです。だから、proresのようなコーデックにどのようなテストが適切であるかについてはよくわかりません。short-GOP x264がうまく機能しない場合は、mjpegが高速な代替手段になると思います。Linuxディストリビューションにはasmで高速化されたjpegの実装があり、非常にシンプルなコーデックです。必要に応じて品質を上げたり下げたりして、品質とファイルサイズ+エンコード/デコード速度のトレードオフを図ることができます。古くからありますが、本当に高速なイントラ専用コーデックが必要な場合は、x264を上回る可能性があります。
x264の場合、x264 --crf 10 --keyint=1 --preset superfast --tune fastdecode （イントラのみ、--avcintra-class設定する他のものは一切使用しません。）注superfast（CABACなし）、またはがfaster、ultrafast損失のある操作にはおそらく最適ではありません。超高速はそれほど速くなくても多くの品質を失うと思います。より低い品質（より高いcrf）を使用するほど、より良いエンコードを見つけるためにCPU時間をもう少し費やす価値があります。ただし、この多くはおそらくGOPサイズ= 1には関係ありません。
GOPサイズ> 1で、エンコードで非常に多くのビットを投げている場合、残差をエンコードするときにより良いインター予測では多くのビットを保存しません（フレーム間のノイズ/粒子/微妙な変化が非常に正確に保持されるため）おそらく超高速で十分です。そうでなければ、--keyint=30おそらく、何か--preset veryfast --crf 12が面白いでしょう。
理論的には、所定のCRF設定での品質はプリセット間で一定でなければなりません。小さいファイル（高速なデコード）を探している場合、品質とエンコード時間のトレードオフは理にかなっています。
ffmpeg -i input.avi -c:v qtrle -pix_fmt rgb24 output.mov。