web-dev-qa-db-ja.com

avconvを使用した2パスエンコーディング

マルチパスエンコーディングのビデオ品質が1パスよりも悪いのはなぜですか？

私がこれを行うと、それは正しいです：

avconv -i video.mpg -s 640x360 -threads auto \
       -vcodec libxvid -b 800k -r 24 -g 300 -bf 2 \
       -acodec libmp3lame -ac 2 -ab 128k -ar 48000 \
       video.avi

これは最悪です：

avconv -i video.mpg -s 640x360 -pass 1 -threads auto \
       -vcodec libxvid -b 800k -r 24 -f avi -an -y /dev/null
avconv -i video.mpg -s 640x360 -pass 2 -threads auto \
      -vcodec libxvid -b 800k -r 24 -g 300 -bf 2 \
      -acodec libmp3lame -ac 2 -ab 128k -ar 48000 \
      video.avi

何が間違っていますか？

video-conversionavconv
5
Tazeg

品質が低下している場合は、おそらく-bフラグを誤って使用しているためです。 sedはビデオのビットレートのみを指しますが、最近のffmpeg/avconv構文の見直しにより、全体のビットレートを指すようになりました。そのため、最初のパスはavconvにビデオで再生する800kbit/sがあることを伝えていますが、2番目のパスはそれが（800-128）= 672kbit/sであると伝えています。

最初のパスで行うことは、2番目のパスが利用する一種のロードマップを作成することです。この場所はアクションシーンであり、より高いビットレートが必要です。これは遅い会話であり、必要なものは少ないです-そのようなこと。誤った情報を処理しているため、ロードマップは正しくありません。

次のように、代わりに-b：v（および-abの代わりに-b：a）を使用します。

avconv -y -i video.mpg -s 640x360 -pass 1 -threads auto -c:v libxvid -b:v 672k -r 24 -f avi -an /dev/null
avconv -i video.mpg -s 640x360 -pass 2 -threads auto -c:v libxvid -b:v 672k -r 24 -g 300 -bf 2 -c:a libmp3lame -ac 2 -b:a 128k -ar 48000 video.avi

また、avconvは入力と同じオプションを使用するため、これらのオプションの多くはおそらく不要です。ビデオのサイズを変更する場合を除き、-s 640x360ビットを省略します。同様に、フレームレートを変更する必要がない限り、-r 24を省略し、サンプリングレートを実際に変更する必要がない限り、-ar 48000を省略します。明らかに、必要なことがわかっている場合はそのままにしておきます。

5
evilsoup