Intel QSV * Linux * FFmpeg * (H.265|VP9)

Intel QSVによる動画エンコーディングを試してみた。

LinuxにおいてIntel QSVはVA-APIを通して利用することができる。 そのため、FFmpegのVA-API機能を使用してエンコードしてみる。

VP9 WebM。

おおよそ基本的なフォーマットに従っているけれども、注意点は-vfオプションだろう。

これはビデオフィルタを指定するのだが、この中でscale_vaapiは動画の画像サイズ(よく解像度と言われるもの)を変更している。 これは、ソフトウェアエンコーディングのものと比べ柔軟性が劣るため、スクリプトで連続処理する場合はよく考えて設定する必要がある。 特にアスペクト比が一定でない場合は注意が必要。

VP9でconstant qualityエンコーディングしたいと考えたのだけど、結局まともな結果は得られなかった。 -qだろうが-qpだろうが、設定は基本的に無視される(もちろん、-b:v 0しているのだけど)。

H.265の動画を作る。

そして、-qp 32のH.265なMP4と、-b:v 2.5MのVP9なWebMの比較が次の通り。

-rw-r--r-- 1 aki aki  43215798  1月 24 14:27 _comp_fuwa.mp4
-rw-r--r-- 1 aki aki  43365795  1月 24 14:30 _comp_fuwa.webm

VP9は非常に荒れている
VP9 2.5Mbps キャプチャ

H.265は良好な画質
H.265 2.5Mbps (qp=32)

VP9のほうは、とても見られたものではない。 オリジナルは171484771バイトのH.264 MP4であるが、

encoder         : Lavf57.25.100
  Duration: 00:02:14.08, start: 0.000000, bitrate: 10231 kb/s
    Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, smpte170m/unknown/smpte170m), 1080x1920 [SAR 1:1 DAR 9:16], 9942 kb/s, 29.88 fps, 29.88 tbr, 15296 tbn, 59.75 tbc (default)

H.265のほうがなんら問題なく見られるのに対して、VP9のほうはちょっと実用に耐えない。 フリーのコーデックを使いたいという気持ちは強いので、何度も実験しているのだけれども、今のところ「高圧縮のH.265並の圧縮度を求めるとひどい結果になる」という結論しか得られていない。

そもそも(VP10が合流した)AV1が「HEVCに迫る」なんて言っている状況を鑑みればそんなものなのかもしれない。 AV1はまだavcodecには載っていないので、WebM勢は遅れが目立ち、このままではWeb配信のみのフォーマットになってしまいそうだ。

WebPが後発のHEIFに飲み込まれそうな情勢を考えても、世界はライセンス問題という頭痛の種をなんとかしようという方向には進まないらしい。

個人的に所蔵するデータについては、恐らくおとなしくH.265/MP4にするのが無難だろう。 公開・配布する場合はVP9も選択肢に入るだろうし、その場合はIntel QSVでエンコードできるのは非常に嬉しいだろう。1

先日のNVENCを使用する方法(Nvidia版, H.264)は次のようなものだった。 どちらかといえばVA-APIにして欲しいなぁ…


  1. 自分で所蔵する(オリジナルになる)特別な動画データなら時間をかけても構わないが、一時的な自分ではあまり使わないデータであれば瞬間で終わってほしいと思うのが人情だろう。

Linux的ビデオのハードウェアエンコーディング

ネットで検索するとかなりいい加減な情報が溢れているので、 そこまで分かっているわけではないけれどまとめてみた。

「エンコード」

まずencodeとdecodeがわからない記事がいくつか出てくるのでそこから。

  • データを映像/音声にするのがデコード
  • 映像/音声をデータにするのがエンコード

エンコードは動画編集をしているのでなければ、基本的に動画変換のお話。

ハードウェア

ハードウェアでやる、というのはCPUに頼らず、ハードウェア側に搭載された専用のチップを使用してエンコーディングする話をしている。

これにより

  • CPUにかかる負荷が低減できる
  • 速度が向上する(かもしれない)

というメリットがある。

遅いGPUと速いCPUの組み合わせだと速度向上には必ずしもつながらないが。 だが、GPUは非常に速いので高速化する可能性は高い。

最近の盛り上がり

動画処理というか、変換というかではなくて、 「ゲームしながらゲームを録画するため」 だと思う。

ゲームはリソースをいっぱい近く使うので、録画するのは難しい。 処理落ちなどの原因になる。 そんなことがあったら多分ガチなゲーマーは許さない。

録画時はそのまま映像データを収録しているとあまりに巨大ファイルになる。 ゲームのプレイ時間は長い可能性が高いし、これはこれできつい。 というわけで、これをハードウェアにオフロードしてCPUや描画用グラフィックスに負担をかけることなく録画/変換して保存しようということだと思う。

ただ、IntelのQSVは恐らく趣旨が違う。 というのは、こちらは「CPUやメモリにも負担をかける」からだ。 VP9エンコードにもKaby Lakeにも対応していたりするので、もしかしたら動画編集を意識しているのかもしれない。

VA-APIとVDPAU

VA-APIはIntelが、VDPAUはNvidiaが作ったLinux用のハードウェアビデオアクセラレーション用のAPIだ。

それぞれサポートされているのだが、そのサポートに注意がいる。

  • libva-vdpau-driverはVA-APIをラップしてVDPAUに投げる
  • libvdpau-va-glはVDPAUをラップしてVA-APIに投げる

このため

  • NVIDIAはVA-APIは使えるけれど実際はVDPAUを使用する
  • IntelはVDPAUは使えるけれど実際はVA-APIを使用する

ちなみに、AMDのオープンソースドライバ(ATIあるいはamdgpu)はVA-APIドライバとしてlibva-mesa-driver(とmesa)と、libva-vdpau-driverの2種類の方法がある。 前者であればVA-APIを直接取り扱う。後者であればVDPAUに流す。

そして、重要な点

  • VDPAUはハードウェアデコード用
  • VA-APIはハードウェアエンコード/デコード用

つまり

  • NvidiaのカードはVA-APIをサポートしていないのでこの方法でのエンコードは無理
  • AMDのカードはlibva-mesa-driverを使わないとハードウェアエンコードできない

ハードウェア側機能

IntelにはQSV, NvidiaにはNVEnc, AMDにはVCEがある。

QSV (Quick Sync Video)

デコードだけじゃなかったんだぁ…と思ってしまったけれど、 実はIntelのビデオアクセラレーションは割とLinuxに手厚い。

QSVの利用はIntel Media Server Studioを要求されるけれども、色々と条件が厳しいし、フリーではない(無料ではあるけれど)。

性能的には劣るもののVA-APIから叩けるらしい。

VCE (Video Coding Engine)

デコード用のUVD(Unified Video Decoder)とセットのAMDの機能。

VA-API経由で叩ける。

NVEnc

Nvidiaのエンコード用ビデオアクセラレーション。 Pascal世代になってとっても速くなったらしい。

Maxwell Gen2でもHEVC 720p高画質で300fpsとか言っているのでGPUすごい。

QSVのほうが速いとか言っている人がいるけれども、多分そんな環境まずない。

画質が割と腐っているけれど、H265がH264とほぼ同じ速度で変換できるので、H265にすればだいぶよろしくなる。 H265エンコードはMaxwellからのサポート。

エンコーダと画質のお話

ハードウェアエンコードを行う場合、実際のデータ変換処理を行う「エンコーダ」としてハードウェアへのアダプタを指定する。

つまり、NVEncを使う場合、libx264の代わりにnvenc_h264を使うことになる。 なのでエンコーダオプション(-crfとか)も変わる。

結果的に変換のされ方が変わる。 同一のクオリティを要求しても同じデータにはならない。

そして、ハードウェアエンコードを行った場合の画質、あまりよくない。 H.264でq=30くらいまで落とすとものすごくわかりやすいことになる。 q=28でも厳しい。

画質が悪いのだからできれば「保存したい」よりも「消すのはちょっと…」くらいのモチベーションの動画で使いたいところなのだが、 そういう動画こそサイズを小さくしたい。 ところが、ハードウェアエンコーダでサイズを小さくすると画質が目立って悪い。 だいぶ悩ましい話だ。

ffmpegでエンコード

Linuxの動画はffmpegで変換するものでしょう?

というわけで、QSVとVCEはVA-APIに対応しているのでVA-APIで。

ffmpeg -vaapi_device /dev/dri/renderD128 -i input.mp4 -vf 'format=nv12,hwupload' -c:v h264_vaapi output.mp4

エンコードもハードウェアでやればより軽い。

ffmpeg -init_hw_device vaapi=foo:/dev/dri/renderD128 -hwaccel vaapi -hwaccel_output_format vaapi -hwaccel_device foo -i input.mp4 -filter_hw_device foo -vf 'format=nv12|vaapi,hwupload' -c:v h264_vaapi output.mp4

-qオプションは指定できるみたい。

ffmpeg -init_hw_device vaapi=foo:/dev/dri/renderD128 -hwaccel vaapi -hwaccel_output_format vaapi -hwaccel_device foo -i input.mp4 -filter_hw_device foo -vf 'format=nv12|vaapi,hwupload' -c:v h264_vaapi -q 28 output.mp4

Nvidiaがひとり独自路線なのはちょっと気になるけれども、使いやすいのはnvencのほう。

ffmpeg -i input.mp4 -c:v nvenc_h264 -q 28 output.mp4

qの値など実際は探り探りやっていくしかない感じ。

あなたのビデオカード、眠ってませんか

GPUは基本的に積極的に働かせないと動かない子なので、 結構なリソースを眠らせている可能性は結構ある。

Linux環境だとCinnamonとKDE Plasmaがハードウェアアクセラレーションに対応しているため、 割と最近のIntel CPUやAMD APUを搭載しているコンピュータだとCPU的にはXFceやMATE、LXDEなんかよりよっぽど軽かったりもする。

そういうのがあればある程度は働いてくれるのだが、これもビデオカードの機能のごく一部を使っているだけ。 ちなみに、OpenGL用のアクセラレータを使っている。

この状態でもデコーダやエンコーダは遊んでいるので、せっかくのリソース活用してあげてください。

ハードウェアエンコーダの画質はちょっと微妙だけども。

ffmpegでスクリーンキャスト&ウェブカメラ撮影

ほぼArch wikiの通りではあるけれども

スクリーンキャスト

スクリーンキャストはPCの画面を録画する。

recordMyDesktopやIstanbulを使うことが多いかもしれないが、処理が遅くて録画した後が大変だし、音声に自由度がない。

とりあえずFullHDでキャストしてみた。

$ ffmpeg -f x11grab -video_size 1920x1080 -i $DISPLAY -f alsa -i pulse -acodec aac -vcodec libx264 -preset ultrafast -qp 0 tmp/test.mp4

これで左上から1920×1080の領域が録画される。音声はpulse経由であり、マイク保存することもできるし、モニターを保存することもできるし、特定のアプリケーション出力を保存することもできる。

特に音声を記録しないなら

$ ffmpeg -f x11grab -video_size 1920x1080 -i $DISPLAY -acodec aac -vcodec libx264 -preset ultrafast -qp 0 tmp/test.mp4

ALSAでやりたいなら

$ ffmpeg -f x11grab -video_size 1920x1080 -i $DISPLAY -f alsa -i default -acodec aac -vcodec libx264 -preset ultrafast -qp 0 tmp/test.mp4

特定のウィンドウを記録するにはxwininfoを使えばいける。

Gist

使い方としては、-w(ウィンドウモード)、-m(マイク有効)オプションを受け付ける。

ウェブカム録画

$ ffmpeg -f alsa -i pulse -f v4l2 -s 1280x720 -i /dev/video0 -acodec flac -vcodec libx264 -preset ultrafast tmp/test.mkv

意外ときつい。解像度を落とせばいける。

ただし、guvcviewなどで録画するよりはずっと快適。

PulseAudio応用

マイクから録る

単純にpavucontrolから録音しているアプリケーションのマイクデバイスを選択すれば良い

モニターを録る

入力装置をAll Expect Mintorsではなく、All Input Devicesにすればモニターも見える。
あとは録音しているアプリケーションでモニターを選択すれば良い

特定のアプリケーションだけ録る

$ pacmd load-module module-null-sink sink_name=MySink
$ pacmd update-sink-proplist MySink device.description=MySink

といった感じでSinkを作成、これがスピーカーとして入るのでアプリケーションの出力先にする。
これだけでは追加されるのはモニターだけでマイクロフォンはないが、Monitor of Null 出力を選択すればそのアプリケーションだけ取れる。

もちろん複数のアプリケーションをまとめて録音することも可能。

エンコード

ultrafastで録画したデータは非常に大きいので、圧縮する。

圧縮がしやすいように用意した~/.zshrc.d/40-zaliasesは以下の通り

## Video Conversion ##

videocomps() {
  #WebM? H.264? H.265?
  case $1 in
  264)
    case $2 in
    best)
      ffmpeg -i "$3" -vcodec libx264 -preset veryslow -crf 18 -strict -2 _comped_"${3:r}".mp4
      ;;
    goodslow)
      ffmpeg -i "$3" -vcodec libx264 -preset slow -crf 18 -strict -2 _comped_"${3:r}".mp4
      ;;
    good)
      ffmpeg -i "$3" -vcodec libx264 -crf 18 -strict -2 _comped_"${3:r}".mp4
      ;;
    normal)
      ffmpeg -i "$3" -vcodec libx264 -crf 23 -strict -2 _comped_"${3:r}".mp4
      ;;
    light)
      ffmpeg -i "$3" -vcodec libx264 -crf 28 -strict -2 _comped_"${3:r}".mp4
      ;;
    mobile)
      ffmpeg -i "$3" -vcodec libx264 -crf 36 -strict -2 _comped_"${3:r}".mp4
      ;;
    esac
    ;;
  265)
    case $2 in
    best)
      ffmpeg -i "$3" -vcodec libx265 -preset veryslow -x265-params crf=18 -strict -2 _comped_"${3:r}".mp4
      ;;
    verygoodslow)
      ffmpeg -i "$3" -vcodec libx265 -preset slow -x265-params crf=18 -strict -2 _comped_"${3:r}".mp4
      ;;
    verygood)
      ffmpeg -i "$3" -vcodec libx265 -x265-params crf=18 -strict -2 _comped_"${3:r}".mp4
      ;;
    good)
      ffmpeg -i "$3" -vcodec libx265 -x265-params crf=23 -strict -2 _comped_"${3:r}".mp4
      ;;
    normal)
      ffmpeg -i "$3" -vcodec libx265 -x265-params crf=28 -strict -2 _comped_"${3:r}".mp4
      ;;
    light)
      ffmpeg -i "$3" -vcodec libx265 -x265-params crf=32 -strict -2 _comped_"${3:r}".mp4
      ;;
    mobile)
      ffmpeg -i "$3" -vcodec libx265 -x265-params crf=38 -strict -2 _comped_"${3:r}".mp4
      ;;
    esac
    ;;
  webm)
    case $2 in
    best)
      ffmpeg -i "$3" -c:v libvpx-vp9 -b:v 0 -threads 8 -crf 10 -c:a libopus -f webm _comped_"${3:r}".webm
      ;;
    verygood)
      ffmpeg -i "$3" -c:v libvpx-vp9 -b:v 0 -threads 8 -crf 18 -c:a libopus -f webm _comped_"${3:r}".webm
      ;;
    good)
      ffmpeg -i "$3" -c:v libvpx-vp9 -b:v 0 -threads 8 -crf 23 -c:a libopus -f webm _comped_"${3:r}".webm
      ;;
    normal)
      ffmpeg -i "$3" -c:v libvpx-vp9 -b:v 0 -threads 8 -crf 28 -c:a libopus -f webm _comped_"${3:r}".webm
      ;;
    light)
      ffmpeg -i "$3" -c:v libvpx-vp9 -b:v 0 -threads 8 -crf 33 -c:a libopus -f webm _comped_"${3:r}".webm
      ;;
    mobile)
      ffmpeg -i "$3" -c:v libvpx-vp9 -b:v 0 -threads 8 -crf 48 -c:a libopus -f webm _comped_"${3:r}".webm
      ;;
    esac
    ;;
  esac
}

CRF値はH.264以外はちゃんとデータを出していない。
参考までにVP9 CRF33でエンコードするとこんな感じだった。

$ ls -lh
合計 50M
-rw------- 1 aki users 3.1M  3月 14 16:50 _comped_purebuilder.webm
-rw------- 1 aki users  47M  3月 14 16:46 purebuilder.mp4

シンプルなスクリーンキャストとはいえ、mobileはさすがにきつい。

Linuxにおけるビデオフォーマットの取り扱い(H.264/H.265/VP9 WebM)

ビデオのファイルフォーマットについて

ビデオのファイルフォーマットは、

  • 動画部分
  • 音声部分
  • それをまとめる部分

の3パートからなる。
今回は

  • H.264+AACのMPEG-4 Part14(mp4)
  • H.265+AACのMPEG-4 Part14(mp4)
  • VP9+OpusのWebM

の3種類についての検討となる。

検討すべき点

画質とファイルサイズ

画質面では基本的に非圧縮が最良である、と考えて良い。
しかし、それではあまり巨大なデータになってしまうので、圧縮することになる。
非可逆圧縮を行えば画質は劣化する。これは、音声と同じ理屈である。可逆圧縮も存在するが、やはりサイズが大きく、現実的ではないとみなされている。

そもそもの話として、そんな巨大すぎるデータを扱うことは難しいため、動画素材が出力される時点でなんらかの圧縮がされているというのが普通だ。
それは、例えば録画ソフトだったり、ビデオカメラだったりだ。録画の場合、録画時に圧縮されるだけでなく、録画ソースがデジタル動画なら、その動画自体が既に圧縮されていて、2回目の圧縮をかけることになる。

いずれにせよ、非圧縮の映像ソースが手に入らないのであれば、映像ソースの状態が最良である。画質向上のための加工をすれば改善する可能性はあるが、それは普通ではない。

そこからさらにファイルサイズを小さくするために変換するか、あるいは取り扱いやすさのために変換するか、ということになる。
場合によっては、カメラから出力されるデータの圧縮形式を選べる、という場合もある。

つまりここで問題になるのは、ファイルサイズに対して画質の劣化がどれくらい抑えられるか、である。

速度

エンコード時に時間がかかるコーデックは、動画を変換してファイルとして出力する際に時間がかかる。

デコード時に時間がかかるコーデックは、再生が間に合わず飛んでしまうかもしれない。

ただ、実感としては、デコード時の所要時間の問題というよりは、ビットレートが高い動画は飛びやすい、という印象だ。
ただし、動画再生の重さには関係する。

ハードウェアアクセラレーション

デコードが重いコーデックであっても、ビデオカードがそのデコードを担うことができるのであれば、それは問題にならない。

これは、プロセッサ、ドライバ、そしてアクセラレーションの仕組みの全てがサポートしていなければ利用できない。

フォーマット

H.264

H.264(≈MPEG-4 AVC)は2003年に勧告された新しいフォーマットで、現在の主流といっていい。
MPEG-1から続く基本的な動画圧縮アルゴリズムを改良したもので、かなりの高圧縮でも目立った劣化が少ないことから主流となった。

高機能・高圧縮・高画質とメリットは大きいが、H.264を「使わない理由」といえば、エンコードに時間がかかりすぎるため、というのが一般的だ。

一般的なので、とりあえず迷ったらH.264で良いと思う。
LinuxではVDPAU/VA-APIにおいて、nVidiaグラフィックスにオープンソースまたはプロプライエタリのドライバ、さらにAMDグラフィックスにRadeonまたはCatalystドライバでH.264アクセラレーションがサポートされるというのは大きなメリットだろう。
どうもAMD APUでうまく動作してくれていないが。

nVidia Quadro 2000グラフィックスにLinux 4.3 + nvidia 1:352.53-1という構成のvdpauinfoはこのようになっている。

H264_BASELINE                  --- not supported ---
H264_MAIN                      41  8192  2048  2048
H264_HIGH                      41  8192  2048  2048
H264_CONSTRAINED_BASELINE      --- not supported ---
H264_EXTENDED                  --- not supported ---
H264_PROGRESSIVE_HIGH          --- not supported ---
H264_CONSTRAINED_HIGH          --- not supported ---
H264_HIGH_444_PREDICTIVE       --- not supported ---

Quadro 2000はFeature set Cなのでこうなっているのだろう。

非常に扱いやすい、お勧めできるフォーマットだ。
可搬性からいえば、MPEG-4のほうが上かもしれない。ちなみに、MPEG-4 Part2は、H.263がベースで、H.264と比べると劣っている。

H.265/HEVC

承認されたのが2013年という非常に新しいコーデックで、携帯向け映像配信から8kビデオまで幅広くターゲットにしている。
dアニメストアがH.265を採用していることで知られている。

同等の画質でH.264の半分の容量、という触れ込みだ。
非常に優れたフォーマットだが、新しすぎて結構厳しい。ハードウェア支援が追いついておらず、それでいて処理は非常に重い、というのが辛い部分でもある。
将来的には、H.265を置き換えていくのだろう。

H.265をサポートするFeature set FはGTX950/960のみで、TITANも含まない。QuadroシリーズはM6000まで含めて最大でもEまでだ。H.265が新しいフォーマットであることもあり、対応はまだまだ進んでいない、最新のカードでようやく対応がはじまったということなのだろう。

ちなみに、エンコード速度の差はあまりなかった。
というよりも、私の環境ではH.264の高品位エンコードが結構遅いので、H.265を若干軽い設定にしたこともあってか、2.1fpsでどちらも同じだった。

VP9 (WebM)

H.264はかなり複雑な特許関係になっているし、H.265はMPEG LAが特許を保有している。
こうしたことを嫌う人は、かなりいる。

Mozilla Firefoxは、以前mp4系ではなく、Ogg Theoraをサポートしていくことを表明したことがある。

Ogg Theoraについてはちょっと説明が必要だろう。Oggというのは、そもそもコンテナフォーマットで、任意の数の対応したコーデックを格納できる。一番有名なのは非可逆圧縮音声コーデックのVorbisで、OggコンテナフォーマットにVorbisを格納したものがOgg Vorbisだ。

そして、可逆圧縮音声コーデックのFLACを格納したものがOgg FLAC(FLACはOggに格納しないほうが普通)、動画コーデックのTheoraを格納したものがOgg Theoraだ(音声はSpeex, Vorbis, CELT, Opus, FLAC, OggPCMのどれか)。

このあたりは、Xiph.orgが開発したロイヤリティフリーコーデック/フォーマットで、OSSの一翼を担うと自負するMozillaなりのプライドだったのだろう。
しかし、そもそもOn2のVP3をベースにしたTheoraはあまり品質の良いものではなく、結局普及もしないままだ。オープンなのは良いことだが、Ogg Theoraをサポートしているプレイヤーも少なく、最初から影の薄い存在だ。

動機は似ているが、よりアグレッシヴに、技術的な主導権を握ろうとしたのがChromeの開発を行うGoogleだ。GoogleはChromeへの搭載とYouTubeでの採用の両面から働きかけている。

GoogleはコンテナフォーマットWebMを開発し、VPコーデックを開発してきたOn2を買収してその最新コーデックであるVP8を採用、音声フォーマットはVorbisをメインに採用してきた。
VP8に関しては特許問題があったが、最初から利用者に対する開放という方針は貫かれている。その後特許問題をライセンス契約締結によって解決し、自由に使えるようにした。

主導権を得るために、かなり献身的な振る舞いをしていると言ってもいい。品質面に問題があるTheoraに対して、VP8を採用するWebMは品質面でもH.264+AACのmp4に対抗できる存在だった。
現在においてもこの試み、つまりオープンソースによってデファクトスタンダードを塗替え、フォーマットを統一してリーダーボードを握るというのは依然として野心的だが、挑戦は続いているし、かつ悪くない話でもあり失敗もしていない。

そして、WebMの第二世代ともいうべきサポートが、VP9ビデオコーデックとOpusオーディオコーデックの採用だ。

VP9は、VP8に対して同一画質でビットレートを半分にする、ということなので、その目標はH.264に対するH.265と等しい。仕様がH.265と比べてもシンプルで、YUV444, 12bit色深度, アルファチャンネル, 深度チャンネル, 8kと機能はむしろ勝ってさえいる。
2011年にスタートしたプロジェクトで、後追いだったVP8とは違い、H.265に対して一歩前をいく状況で始まっている。

さらに、音声コーデックのOpusは、スピーチ向き音声フォーマットのSpeex、あるいは音楽向けコーデックのVorbisを越える存在として登場している。
IETFによって開発され、RFCで標準化され、リファレンス実装がBSDライセンスでリリースされている。Xiph.orgが手動するVorbisやFLACよりも、さらに文句なしにフリーだ。
音質がいいだけでなく、低レイテンシも実現している。ビットレートによって(場合によってはシームレスに)モードが切り替わり複数の仕様が混在するのは美しいとは言えないように思うが、実際に品質は素晴らしいのだから文句のつけようがない。
政治的紛争と無縁というわけではないのだが、Vorbisの次を叶えるコーデックではあるだろう。

つまり、完全に特許と制約に基づいたH.265+AACに対して、課題はあれども利用者としては自由に使うことが約束されているVP9+Opusでは、まずそこで魅力がかなり異なる。
しかも品質面でも優れている。

だが、決定的なディスアドバンテージもある。LinuxのVDPAUにおいてどころか、WindowsのPureVideoでさえ、VP9はもちろん、VP8もハードウェアアクセラレーションがサポートされていない。
VP8がサポートされていないということは、将来的にも大きな状況の変化がない限りはVP9も含め、WebMでのハードウェアアクセラレーションはサポートされないのだろう。
H.265のサポートはもう見えている。これは決定的だ。

比較

実際に比較してみた。

エンコーディングはだいたい同じくらいの時間がかかった。VP9+OpusのWebMが3.0fps出ていて1.5倍ちかく速かったが、それでもとても遅いのであまり意味はない。

サイズを見てみよう。

-rw------- 1 aki users 194571866 12月 10 10:59 moto-mad-01.h264.mp4
-rw------- 1 aki users 153719824 12月 10 17:14 moto-mad-01.h265-crf20.mp4
-rw------- 1 aki users  96287262 12月 10 09:13 moto-mad-01.h265.mp4
-rw-r--r-- 1 aki users 492912031  4月 16  2015 moto-mad-01.mov
-rw------- 1 aki users 215367319 12月 10 11:50 moto-mad-01.webm

H.264はCRF18、h265-crf20とWebMはCRF20、h265はCRF24だ。
ちなみに、元のMOVファイルはH.264+AC3である。

CRFが同一基準にならないようにしか見えないので、それぞれのコーデックで画質と容量の関係を探らなければ意味がなさそうだ。
実際、FFmpeg公式で、x265については

default CRF of 28. The CRF of 28 should visually correspond to libx264 video at CRF 23, but result in about half the file size.

と言っていたりする。色々やってみなければ分からないのだが、実際H.265の「劣化が少ない」は納得できる。H.264と比べてもそこは結構違う。H.264でCRFを上げていくとかなり乱れるので、ケータイ向けに用意したりするとはっきりと違ってくるのだ。

ちなみに、この生成物の感覚的な画質の比較でいうと

  • H.264は若干粗い。滑らかさが足りない
  • H.265は綺麗。CRF20かCRF24かの違いはほとんど分からない
  • WebM(VP9)はなめらかに見えるが、動きが激しいところではざらついて見える

結論

  • 今のところはH.264を使うのが可搬性を考えてもまとも
  • どうしてもファイルサイズを落としたい場合、H.265は結構いい
  • とりあえずVP9を使うメリットは、OSS派以外にはなさそう。エンドユーザーから見るとこだわりがない限り動機としてはかなり弱い
  • 将来的にはH.265に移っていくと考えて良いと思う
  • WebMがもっと普及して、ハードウェアアクセラレーションも対応してくれると嬉しい
  • そもそも、現在大抵の動画はH.264になってるし、普通の人がコーデックを選ぶ機会があまりないと思う
  • 昔のWMVやRM抱えてる人はWebMにしちゃうのもいいかもよ

Linux Tips

YouTubeのプレイリストからタイトルを抽出する

結局使わなかったのだが、ワンライナーで書いた。 比較的素直なHTMLなので解析は簡単。行指向ではないので、PerlでなくRubyにした。

$ curl 'https://www.youtube.com/playlist?list=<playlistid>' | ruby -e "s = STDIN.read" -e 's.scan(/<a class="[^"]*pl-video-title-link[^"]*"[^>]*>(.*?)</m) {puts $1.strip }' | grep -v 動画は削除されました

ffmpegでh.264/aacな360pのmp4を

元動画は1080pのmovまたはmp4。 オーディオはいじらず、元々aac(ac3)。

$ ffmpeg -i <infile> -vcodec libx264 -s 640x360 -crf 34 -strict -2 <outfile>.mp4

ちなみに480p(16:9)は720×280。 -crfの値は18-28が推奨されている(小さいほど高ビットレート)が、今回はモバイル向けなので34を指定。

なお、6の増減でビットレートはおよそ1:2の変動となる。

ffmpegでCowon M2向けの動画を作る

COWON M2はXVidとmp3のAVI動画で、解像度は320×240またはWMVをサポートするとある。

WMVだと結構サイズが大きいので、AVIで作る。 ソースは前回と同じくh.264*ac3のMOVまたはh.264*m4aのmp4。

$ ffmpeg -i <infile> -vcodec libxvid -acodec libmp3lame -b:v 372k -b:a 128k -s 320x240 <outfile>.avi

随分としょぼい解像度の上にアスペクト比も壊れる(プレイヤー側で調整することは可能)が、案外見られる。 ただし、360pでも細部は潰れてしまっているのでよく分からない部分は出てしまう。

XineのUIの文字化けを直す

fontにHerveticaを要求しているので、フォントエイリアスを設定すれば良い。

VHS変換用スクリプト

結局Windowsで記録するようにしたため、MPEGファイルをH.265形式に変換するためのスクリプト。

INDIR/SUBDIR/FILE.mpgファイルをOUTDIR/SUBDIR/SUBDIDR-NN.mkvに変換する。

ちょっと工夫をいれることでだいぶ楽にした。

#!/usr/bin/zsh

# Put your videos on a subdirectory under $WORKER_DIR.
WORKER_DIR=$HOME/mov/usr/vhs_converted/worker
# Videos will be put on a subdirectory under $DEST_DIR.
DEST_DIR=$HOME/mov/usr/vhs_converted/recorded/${dir:t}
# if $1 given, use as bitrate value.
bitrate={$1:512k}

for dir in $WORKER_DIR/*
do

typeset -i index=1

if [[ ! -e $DEST_DIR/${dir:t} ]]
then
mkdir $DEST_DIR/${dir:t}
fi

for i in $dir/*
do
ffmpeg -i "$i" -vcodec hevc -b:v $bitrate -aspect 720:480 $DEST_DIR/${dir:t}/${dir:t}-$(printf "%02d" $index).mkv
(( index++ ))
done
done

EasyCap(USBコンポジットビデオキャプチャ)をLinuxで使いたい

安価なUSBキャプチャデバイス、EasyCapを購入した。コンポジットとSビデオを備える。目的はVHSのデジタル記録だ。だが、これが茨の道となった。

Linuxで動作するかは確認しなかった。最悪、Windowsでキャプチャすればいいという考え方からだ。動作自体は以外と簡単で、V4L2ドライバで動くらしい。

ffmpeg -f alsa -i pulse -f v4l2 -s 1280x640 -i /dev/video1 -f mpeg - | vlc -

これで一応は表示できる(USBカメラがあるため、video1となっている。音声はPulseAudioを使用。同様に例えば

ffmpeg -f v4l2 -framerate 25 -video_size 640x360 -i /dev/video1 out.mkv

のように録画することもできる。

H.265で高品質圧縮を狙ったが、

ffmpeg -f alsa -i pulse -f v4l2 -s 640x480 -i /dev/video1 -vcodec hevc -b:v 256k -aspect 640:480 ~/tmp/test.mkv

音は記録できるが、映像はコマ落ち、変色、コマが混ざるなど見られたものではない。

Linuxでのさらなる方法として、VLCを使うという方法がある。ビデオデバイスは「キャプチャーデバイスを開く」で簡単にできるものの、オーディオデバイスはどうすればいいのか悩んでしまった。PulseAudio経由で取得したい場合、pacmd list-sourcesにあるName項目を見て、pulse://Name とすれば取得できる。

これはレイテンシもわずかで非常に快適な視聴が可能。しかし、変換/保存から保存しようとすると、コマ落ちなどが激しい。

他に様々なアプリを試したが、満足な品質にはならなかった。

そこで、ラップトップのWindowsでトライ。純正ソフトであるHoneSteach TVRを使う。だが、まず録画設定に適切なものがない。MPEG-1、MPEG-2とも320×240しかないのだ。DVDを選択することで720×480が選択可能。これで正常に録画できるが、プレビューでは問題のないものの、録画するとかなりコマ落ちが発生する。これはVLCと同様と言ってもいいが、VLCの場合のほうが常にスムーズに録画できないため、こちらのほうがマシだとも言える。

恐らく本当に重要なビデオは2回録画したほうがいいだろう。結構な頻度で発生するため、編集前提にしたほうが良いと思う。

仕方がないのでデスクトップでトライしようとした。DTM用なので余計なソフトウェア(特にデバイスドライバ)は入れたくないのだが、仕方がない…と考えたのだが、Autorunからインストールしようとするとフリーズした挙句、Version mismatchと言われて終了してしまう。ディスクから直接にインストーラを起動すればインストールできるが、起動すると(こちらではMPEG-2で720×480が選べる)、録画を開始した途端に「ディスク容量不足です」と表示され録画が止まってしまう。他に適当な、動作するキャプチャソフトはみつけられなかった。

フラストレーションのたまる結果だ。Lowlatency Kernelならできるといったことがあるのだろうか。