このコマンドを使ってビデオを再エンコードしました。
ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -hwaccel_output_format vaapi -i input.mp4 -c:v h264_vaapi -b:v 1M -maxrate 1.5M output.mp4
結果として得られるビデオには、
Duration: 00:01:03.92, start: 0.000000, bitrate: 1292 kb/s Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], 1159 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc (default)
スクリーンショットは次のようになりますこれ
次に、ビデオをハードウェアでデコードし、ビデオをソフトウェアでエンコードするこのコマンドを使用しました。
ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -hwaccel_output_format vaapi -i input.mp4 -vf 'deinterlace_vaapi=rate=field:auto=1,hwdownload,format=nv12' -c:v libx264 -crf 30 -r 25 output.mp4
その結果、不動産のビデオが完成し、
Duration: 00:01:00.89, start: 0.000000, bitrate: 932 kb/s Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], 798 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc (default)
スクリーンショットは次のようになりますこれ
明らかに、2 番目のビデオのビットレートは低いですが、品質は高くなっています。その理由を知りたいです。また、ハードウェア エンコーディングを使用して 2 番目の結果を実現する方法も知りたいです。
答え1
短い答え: すべては常に妥協であるからです。
より長い答え: ASIC コーデックは、必然的にソフトウェア コーデックに比べて柔軟性や機能性がはるかに劣ります。また、主に、フレーム落ちよりもアーティファクトの方が好ましいリアルタイム ストリーミングなどの高速 / 低消費電力 / 一定ビットレートのアプリケーション向けに設計されています。
答え2
優れたソフトウェア エンコーダーにどれだけ近づけるかはわかりませんが、ハードウェアがサポートしている場合は、より効率的な hevc_vaapi を試すこともできます。
-b:v 1Mしかし、h264_vaapiでは、次のような指定をしない限り、良い結果が得られないので、使用すべきではありません。1500万。
試してください-qp 22（後で値を調整してください）。あるいは、さらに良い方法もあります。
-rc_mode CQP -global_quality 22（後で値を調整します）代わりに。
-compression_level 1低速でより良い品質が得られると思われるものを追加することもできます。
オプションについてはここで説明します:https://ffmpeg.org/ffmpeg-codecs.html#VAAPI-encoders
特に hevc_vaapi を試してみたい場合は、こちらも役立つかもしれません: https://www.tauceti.blog/posts/linux-ffmpeg-amd-5700xt-hardware-video-encoding-hevc-h265-vaapi/