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でAmazonプライムビデオを観る

Amazonプライムビデオが始まったので、試してみた。

FirefoxではFlashの更新をするように求められ、VivldiとChromiumで試すと再生が始まらない。

  • firefox 40.0.3-1
  • vivaldi 1.0.219.50-2
  • chromium 45.0.2454.99-1
  • chromium-pepper-flash 1:19.0.0.185-1

カスタマーサービスに問い合わせると、Linux/UNIX OS/Chrome OS上のChromeをサポートしているとのこと。

ダメ元で試してみた。google-chrome 45.0.2454.101-1パッケージで試してみたが、なんとこれで再生できる。

ちなみに、実際にChromeを試してみると、Chromiumと若干挙動が違う。
ChromiumだとZ400ではかなり停止し、動かないがGoogle Chromeなら結構止まるものの一応動く。

この違いはよくわからず、とりあえずPepperFlash全般での再生を可能にするようお願いした。

Manjaro Linux 0.8.13 セットアップ (5) Z400編

はじめに

システム更新

$ sudo pacman -Syuu

Grub設定。nomodesetを入れる

$ sudo nano /etc/default/grub

最新カーネル

$ sudo mhwd-kernel -i linux42

ビデオカード

$ sudo mhwd-gpu --setgl nvidia

再起動。

パッケージインストレーション

  • nss-mdns
  • bind-tools
  • encfs
  • ctags
  • leafpad
  • zsh

ホスト設定を行う。

必要ならchsh

  • medit
  • geany
  • geany-plugins
  • smplayer
  • smplayer-themes
  • smplayer-skins
  • opera-developer
  • cinnamon
  • plasma
  • kde-applications
  • fcitx-kkc

X関係に問題が出るので、Zshでホームディレクトリ上で(多分、extended_globを伴って)

$ rm .[xX](^(profile))

入力関係の設定をしておく。

  • emacs
  • xsane
  • fetchmail
  • spamassassin
  • razor
  • tasque
  • skype
  • skype-call-recorder
  • openssh
  • sshfs

sshの設定

  • lv
  • w3m
  • amarok
  • audacious
  • audacious-plugins
  • libcue
  • audacity
  • sox
  • zsh
  • gtkhotkey
  • libgcrypt15
  • inkscape-gtk3-bzr
  • sylpheed
  • ttf-tahoma
  • fcitx-anthy
  • ttf-ricty
  • ttf-migmix
  • ttf-rounded-mplus
  • ttf-migu
  • ttf-sawarabi-gothic
  • ttf-hanazono
  • ttf-mikachan
  • ttf-sawarabi-mincho
  • ttf-mona
  • ttf-sazanami
  • ttf-monapo
  • ttf-kibitaki
  • ttf-mplus
  • ttf-ume
  • ttf-kochi-substitute
  • ttf-ohruri
  • ttf-vlgothic
  • ttf-koruri
  • ttf-vlkoruri

Infinality, Java, Mozc-UTは猛烈に時間がかかる。

  • cairo-infinality
  • fontconfig-infinality
  • freetype-infinality
  • jre8-openjdk-infinality
  • fcitx-mozc-ut

続き

  • kde-gtk-config
  • ttf-tahoma
  • bundler
  • fcitx-anthy

    nVidia向けのビデオ関連。

  • libva-vdpau-driver
  • gst-vaapi

続き

  • gtk-theme-preference
  • font-manager
  • gtk-chtheme
  • alsaplay
  • gedit
  • gedit-code-assistance
  • gedit-plugins
  • evince
  • gnome-terminal
  • tomboy
  • mcomix
  • gnome-screenshot

Gnome Screenshotは設定が必要

  • xlhtml
  • vivaldi

Vivldiは必要か??
Wine関連

  • wine
  • winetricks
  • twine
  • wine-mono
  • q4wineyaourt
  • wine_gecko

Haskell (for pandoc)

  • ghc
  • cabal-install
  • alex
  • happy
  • texlive-core
  • texlive-langcjk

続き

  • chromium-pepper-flash
  • dialog
  • perl-tk
  • psutils
  • ruby-kramdown
  • livestreamer

ウェブブラウザ。

  • midori
  • qupzilla
  • rekonq

続き

  • xnviewmp
  • nkf

Gtk+2テーマ関連

  • oxygen-gtk2
  • lib32-qtcurve-gtk2-1.8.18-1
  • lib32-qtcurve-qt4-1.8.18-1
  • lib32-qtcurve-utils-1.8.18-1
  • qtcurve-gtk2-1.8.18-3
  • qtcurve-qt4-1.8.18-3
  • qtcurve-qt5-1.8.18-3
  • qtcurve-utils-1.8.18-3

Gtkテーマ, Sylpheed, Leafpad

Gtk+2アプリケーションの中に、Gtkテーマを原因にSegmentation faultを起こす奴がいる。

SylpheedはGtk+2専用テーマでなければいけない。場合によってはフォールバックできるが、できない場合もある。フォールバックできる場合も起動時間が全く異なってくる。

そこで、Gtk+ 2専用のOxygen-Gtkにしたのだが、なんとLeafpadはOxygen-Gtkで動かない(!)

QtCurveが最も簡単に解決してくれるが、それも嫌なので、Leafpadだけは代替プログラムを書いた。

#!/bin/sh

export GTK2_RC_FILES=$HOME/lib/alt-gtkrc-2.0

exec leafpad

で、alt-gtkrc-2.0でQtCurveを指定している。

Gtk+2フルなテーマは

  • Clearlooks
  • Industrial
  • Mist
  • Redmond
  • ThinIce
  • Xfce-redmondxp
  • Xfce-kolors
  • Xfce-dawn
  • Xfce-dusk
  • Xfce-cadmium
  • Silver

もしかするとoxygen-gtk3-gitを入れるとダメかもしれない。

なお、Gtk3はCinnamonで、Gtk2はgtk-chthemeで設定。

文字入力設定

入力関係のため、~/.xprofile

export GTK_IM_MODULE=fcitx
export GTK2_IM_MODULE=fcitx
export GTK3_IM_MODULE=fcitx
export QT_IM_MODULE=fcitx
export XMODIFIERS="@im=fcitx"
export DefaultIMModule=fcitx
export PATH=/home/aki/bin:$PATH

ログアウトしてログインしなおしたほうが良い。
gtk-query-immodules-*は必要なかった。

Gnome Screenshot

デフォルトの保存場所を変更する。

gsettings set org.gnome.gnome-screenshot auto-save-directory /path/to/directory

Maxthon

リポジトリ落ちしているので

$ git clone --depth=1 git://pkgbuild.com/aur-mirror.git
$ cd aur-mirror/maxthon-browser
$ makepkg
$ sudo pacman -U maxthon-browser-1.0.5.3-4-x86_64.pkg.tar.gz

英数キーでCaps Lockになる

Archのevdevがいうこときかなくなっているので、.xprofileあたりに

setxkbmap -model jp106 -layout jp

Pandoc

$ export PATH=$HOME/.cabal/bin
$ cabal update
$ cabal install pandoc

openSSH

$ sudo systemctl start sshd
$ sudo systemctl enable sshd

ホスト設定

MDNS (Zeroconf)

/etc/nsswitchhost項目にmdns_minimalを追加。filesよりも後に。

fcitx-mozc-utのために

/etc/hostsdig japanese-usage-dictionary.googlecode.comした結果に基づき、このホストをIPv4で決め打ち。

ビデオの設定

Quadro2000でのVDPAUについては、単純にnon-freeでインストールしていれば、有効になっている。
nvidia-utilsでOKだからだ。

VA-APIについては、libva-vdpau-driverをインストールし、環境変数$LIBVA_DRIVER_NAMEの値にvdpauをセットするようにすれば良い。
私は~/.xprofileに記載した。

Smplayerは「ビデオ」タブで出力ドライバーvdpauに、
パフォーマンスタブのハードウェアデコードvdpauにする。

VLCについては、ハードウェアアクセラレーションによるデコードX11のVA-APIビデオデコーダーに設定する。

Flashは/etc/adobe/mms.cfgのコメントアウトされているEnableLinuxHWVideoDecodeを有効にする。


追記

Conkyを触ってみたのだが、AMD APUで発生していた

  • execiしていると2回目から表示が消える
  • RSSが取れないことが多い

RSSがとれないというのは、RSSのエントリが表示されない状態になる。Conkyの組み込みrssの話だ。取れたかとれなかったかの状態は永続するが、取れないことが圧倒的に多く、5つのRSSをまとめている部分に関しては、何十回も起動・停止しなければ十分に表示できなかった。

また、Conkyの負担もかなり大きかったので、結局使用をやめていたけれど、Z400になってなんの問題もなくなった。

やはりLinuxにはQuadroだ。

VDPAU / VAAPI * AMD A10 kaveri / Cinnamonが立ち上がらない

LinuxでのGPUハードウェアアクセラレーションつきでの再生のトライ。

設定はわかっているが動作のためにセットアップ。

VDPAUを利用するため、libvdpau-va-glとlibva-xvba-driverのインストールを行い、/etc/profile.d/vdpau_vaapi.sh

#!/bin/sh
export VDPAU_DRIVER=va_gl

と設定して実行可能に。(root:root 744)。再起動して有効化できる。 別パッケージのvdpauinfoによると

libva info: VA-API version 0.38.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/dri/fglrx_drv_video.so
libva info: Found init function __vaDriverInit_0_33
libva info: va_openDriver() returns 0
display: :0.0   screen: 0
[VS] Software VDPAU backend library initialized
API version: 1
Information string: OpenGL/VAAPI/libswscale backend for VDPAU

Video surface:

name   width height types
-------------------------------------------
420     1920  1080  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 
422     1920  1080  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 
444     1920  1080  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 

Decoder capabilities:

name                        level macbs width height
----------------------------------------------------
MPEG1                          --- not supported ---
MPEG2_SIMPLE                   --- not supported ---
MPEG2_MAIN                     --- not supported ---
H264_BASELINE                  51 16384  2048  2048
H264_MAIN                      51 16384  2048  2048
H264_HIGH                      51 16384  2048  2048
VC1_SIMPLE                     --- not supported ---
VC1_MAIN                       --- not supported ---
VC1_ADVANCED                   --- not supported ---
MPEG4_PART2_SP                 --- not supported ---
MPEG4_PART2_ASP                --- not supported ---
DIVX4_QMOBILE                  --- not supported ---
DIVX4_MOBILE                   --- not supported ---
DIVX4_HOME_THEATER             --- not supported ---
DIVX4_HD_1080P                 --- not supported ---
DIVX5_QMOBILE                  --- not supported ---
DIVX5_MOBILE                   --- not supported ---
DIVX5_HOME_THEATER             --- not supported ---
DIVX5_HD_1080P                 --- not supported ---
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 ---
HEVC_MAIN                      --- not supported ---
HEVC_MAIN_10                   --- not supported ---
HEVC_MAIN_STILL                --- not supported ---
HEVC_MAIN_12                   --- not supported ---
HEVC_MAIN_444                  --- not supported ---

Output surface:

name              width height nat types
----------------------------------------------------
B8G8R8A8         457866064 457866064    y  
R8G8B8A8         457866064 457866064    y  
R10G10B10A2      457866064 457866064    y  
B10G10R10A2      457866064 457866064    y  
A8               457866064 457866064    y  

Bitmap surface:

name              width height
------------------------------
B8G8R8A8         16384 16384
R8G8B8A8         16384 16384
R10G10B10A2      16384 16384
B10G10R10A2      16384 16384
A8               16384 16384

Video mixer:

feature name                    sup
------------------------------------
DEINTERLACE_TEMPORAL             -
DEINTERLACE_TEMPORAL_SPATIAL     -
INVERSE_TELECINE                 -
NOISE_REDUCTION                  -
SHARPNESS                        -
LUMA_KEY                         -
HIGH QUALITY SCALING - L1        -
HIGH QUALITY SCALING - L2        -
HIGH QUALITY SCALING - L3        -
HIGH QUALITY SCALING - L4        -
HIGH QUALITY SCALING - L5        -
HIGH QUALITY SCALING - L6        -
HIGH QUALITY SCALING - L7        -
HIGH QUALITY SCALING - L8        -
HIGH QUALITY SCALING - L9        -

parameter name                  sup      min      max
-----------------------------------------------------
VIDEO_SURFACE_WIDTH              -  
VIDEO_SURFACE_HEIGHT             -  
CHROMA_TYPE                      -  
LAYERS                           -  

attribute name                  sup      min      max
-----------------------------------------------------
BACKGROUND_COLOR                 -  
CSC_MATRIX                       -  
NOISE_REDUCTION_LEVEL            -  
SHARPNESS_LEVEL                  -  
LUMA_KEY_MIN_LUMA                -  
LUMA_KEY_MAX_LUMA                -  

H.264しかサポートできていない?

VAAPIはAMD APU A10 Kaveriで必要なのはlibva-xvba-driverなので、それだけでOK。Catalystドライバは既に使用している。 Mplayerはmplayer-vaapiをAURから導入すれば良いということだが(コマンドラインオプションは必要。Wikiは英語版mplayerの項目でのみ、AURにあることが示されている。communityからdropしたパッケージ)、現在のところ鍵が検証できない(手動追加しても受け付けない)ので試していない。 SMplayerはVAAPIはIntelのみだと言ってくる。

結局うまく動いていない気がする。

Cinnamonが立ち上がらない

再起動すると、Cinnamonが立ち上がらなくなった。

待たされた上でデフォルトの壁紙が表示され、

Cinnamonはクラッシュしました

と表示される。

~/xsession-errorsを調べると、~/.config/dconfがPermission Deniedになっている。

ls -ldR ~/.config/dconf

したところ、ごっそりとパーミッションがroot:rootのmask077になっている。 chownしたのだが、chownしても何度も戻ってしまい、ちょっと苦労した。

Manjaro Linux 0.8.13 setup (3)

"インストール作業"

  • libaacplus
  • evince
  • gedit
  • gedit-plugins
  • gedit-core-assistance
  • ggjs
  • libgit2-glib
  • flashplayer-standalone
  • cnijfilter-mp620
  • xfce4-goodies
  • purple-line
  • wireshark
  • dconf-editor
  • expect
  • firefox-aurora
  • gstreamer-vaapi
  • libvdpau-va-gl

ビデオ関連と、あとはこれまで使っていて欠如しているものを足した。

firefox-auroraはFlashのOut Of Dateに対応したもの。xfce4-goodiesは中途半端に入っていた。

expectはmkpasswdコマンドのためにある。

ビデオプレイヤーの設定

ビデオのパフォーマンスが非常に悪い。 しかも、えらいCPU大食いなので、調べてみたら、ビデオ再生は無条件にGPUを使う、わけではないようだ。

なお、ビデオカードはAMD A10-7700Kで、AMD Radeon R7ということになる。

VLC

環境設定→入力/コーデック→ハードウェアアクセラレーションによるデコード

がある。だが、VDPAUでもDRM経由のVA-APIでも「開けない」と言われてしまう。なぜかnvidiaドライバーを開こうとしたりしている。

X11のVA-APIならば、ただしくAMD用ドライバーで再生するが、フリーズしたり、盛大なブロックノイズなどが頻発する。

Smplayer

VLCよりも快適な再生ができているSMPlayerは、

環境設定→ビデオ→出力ドライバー

で設定できる。色々あるが、とりあえずgl (高速 - ATI カード)を選択することで改善された。

また、「パフォーマンス」の項目にDecodingがあり、Hardware decodingを選択(vaapiにした)することでハードウェアアクセラレーションが利用可能なようだ。

fetchmailが止まる

fetchmailが受信中に停止。 SIGINTで中断して再開するも止まってしまう。

試してみると、特定サーバーで止まる。 そのサーバーより前に記述されているサーバーは正常に処理される。

どうやら、特定メッセージの受信で止まってしまうらしい。 調べたが、あまり有用な情報はなかった。 IMAPでそのメールを除去すると正常に動作するようになった。

この問題は2回目。

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を要求しているので、フォントエイリアスを設定すれば良い。

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ならできるといったことがあるのだろうか。