たぶん2016/11/02現在では最先端のコーデック(対抗でMozillaのDaalaもありますが)である、VP9(映像)&Opus(音声)エンコードの実験をしてみました。
Windows10上でVirtualBoxを使い、ubuntu-16.10-desktop-amd64を動かしています。

特に記事にするつもりはなかったので、正確な手順は残していないです。apt-getでlibavutilをremoveして再installしてみたりもしたのですが、影響があるかはわかりません。

では手順。
最新のソースを持ってきます。

git clone https://github.com/FFmpeg/FFmpeg
git clone https://chromium.googlesource.com/webm/libvpx
git clone https://git.xiph.org/opus.git

コンパイル。
libvpxは普通の手順で、opusはautogen.shを実行しないとconfigureスクリプトが生成されなかったような気がしますが、特に問題なく入りました。
FFｍpegは実験用ということで、以下のオプションでconfigureしています。

../configure --enable-shared --disable-gpl --enable-libvpx --enable-libopus --enable-avresample --enable-swresample

sharedはあってもなくても良かったのですが、とりあえずenable、
gplは試しにdisable、
vpxとopusを指定、
「swresampleよかavresampleの方が良いぜ」って見た記憶があるんですが、avresampleだけだとインストール後の実行時にオーディオ関連で「'aresample' filter not present」というエラーが出てしまうため、swresampleも指定しました。

なお、
--enable-pic
は、
--enable-shared
と連動するので指定不要なはず。

そしてコンパイルして

ffmpeg

を実行すると、共有ライブラリ(～～.so)にav_vdpau_get_surface_parametersが無いとか言われます。
もう少し調べると該当コードの複数ディスプレイ対応に問題がある模様。ソースを調べると該当部分が、
MAKE_ACCESSORS
と言うマクロ(?)に変わっていました。
なので呼び出し側であるlibavcodec/vdpau.cのav_vdpau_get_surface_parametersをMAKE_ACCESSORSに変更したところ、コンパイルできました。
ただし、何が変わっているのかまでは調べていません。

ffmpeg -i input.mp4 -c:v libvpx-vp9 -pass 1 -b:v 0 -crf 33 -threads 8 -speed 4 \
  -tile-columns 6 -frame-parallel 1 \
  -an -f webm /dev/null

で1パス目のエンコードが始まります。例示されていた設定をそのまま使ったので、不適切な部分もあるかと思います。

パフォーマンスはinputがhrvcの4.5mbps(2704x1520)、core i-7 4770k、通常画質で1パス目が3fps程度。
VirtualBoxを1コアで使っているので、4コア全部割り当てれば12fpsくらいになるのでしょうか?
現時点(2016年)での最新最強環境でも、1CPUでリアルタイムエンコードは難しいですね。
しかも、これまだ1パス目だし。

続いて2パス目

ffmpeg -i input.mp4 -c:v libvpx-vp9 -pass 2 -b:v 1400K -crf 23 -threads 8 -speed 2 \
  -tile-columns 6 -frame-parallel 1 -auto-alt-ref 1 -lag-in-frames 25 \
  -c:a libopus -b:a 64k -f webm output.webm

0.9fpsでした。リアルタイムどころか、実用性すら危ぶまれる数字ですね。今後の改良に期待しましょう。GPUを使えば、いきなり処理能力が1000倍になったりすることもありますし。GPUが使えるアルゴリズムなのかまでは調べていませんが、この手の処理ならば使えないことはないと思いますし、Googleなら何か手は打っているでしょう。それが有料クラウド利用が前提だったりする可能性は十分にありますが。

結果、ファイルサイズは423MBから713MBに、って増えてるじゃねーかっ。どうやら元のファイルよりビットレートが高い設定になっていたようです。

デコードはエンコードした環境(VirtualBox)で画像は出るものの、何故か再生ができない(シークはできて、画像もシークした所に更新される)状態になっていました。
WindowsからMPC-HCで再生した場合は正常に再生され、CPU負荷は8%程度でした。

画質はブロックノイズが乗らない分、元ファイルより良くなったように感じるところもありました。ブロックノイズが乗っていた所がぼかされていたため、内部に「ブロックノイズ除去フィルタ処理」みたいなのが入っているのかもしれません。

現状はエンコードのパフォーマンスが問題ですね。YouTubeの様に一回エンコードして、あとは配信するだけという用途になら、エンコード速度はそれほど重視されないかもしれませんが、軽いに越したことはないでしょう。今後の改良を期待したいところです。