2015年を振り返る (エンコ編)
今年のエンコード周りとか、自分で作ったりしたものとかを振り返ってみる。
動画関連ソフト
x265
今年もだいぶ高速化されてうれしい限り。
lwinput.aui
ついにQSVデコードが追加された。特にH.264デコードでは、CPU使用率の低減という効果があると思う。
透過性ロゴ (改)
ロゴ消しについて、フェードやノイズ除去を適応的に行うという点で、フェードを手動で設定する必要がなくなりとても素晴らしい。
waifu2x
なんかめちゃくちゃ流行っていた。多すぎる派生版はこのあたりにまとめてくださっている方がいる。Aviutl向けには、こちらにあるものがよいと思う。
最初途方もなく重かったので、高速化を多くの方が取り組まれていて、いかに高速化するか、非常に面白かった。まあ基本はconvolutionで、演算自体は非常に簡単なのに、普通に書いたら、メモリロードが多すぎて遅くなるやつだ。この傾向はちょっと行列積に似ている気がする。
高速化の方法をまとめてくださっている方がいらっしゃって、非常に面白く、大いに勉強になる。
最内ループからはじめる深層学習
…読んでみると、なるほど、とは思うのだけど、わたしには技術力(と気合?)が足りないので、こんなコードを組める気がしない…。本当にすごいと思う。
Aviutl
今年はあまり更新がなかった。
Aviutl後継?
Aviutlの後継に関するうわさを聞いた。まあ、それはそれとして、じゃあわたしがなんでAviutlを使うのかという話。
Aviutlを使う理由/Aviutlが素晴らしい理由
0. Windowsで動作する (前提条件)
1. 日本語のUIである (重要)
2. 自動フィールドシフトがある (重要)
3. 比較的通常のマウス操作で直観的に操作しやすい (変わったインターフェースでない、GUI中心のソフトである)
4. エンコードに必要なその他のプラグインがそろっている
aacfaw.aui, delogo.auf, chapter.auf, cutedit.auf, m2v.aui, lwinput.auiなど
5. 困ったらプラグインにより自由に拡張できる。AviutlのAPIに加え、Win32APIを駆使すれば本当にいろいろできる。
6. 内部形式がYUV444。→ 色差の劣化が少ない
7. 内部形式が12bitなので、8bitや10bit出力には十分な精度、一方で16bitではないので演算コストが低い(16bitだったら、桁あふれを防ぐため、32bitでの演算が必須となり、SIMD演算のパフォーマンスが大幅に劣化する)
まあ使い始めた理由はほとんど0～3で、まあそうじゃなかったら使ってなかったかもしれない。
Aviutl本体はもちろん、これまで多くの方々が作ってくださったプラグインが豊富にあるため、Aviutl全体として本当に多くの機能が実現されていて、とても素晴らしいと思う。
Aviutlの困ったところ
1. メモリ4GB制限 (32bitプロセス)
2. Unicode非対応
3. 多重音声非対応
4. プラグイン多重使用非対応
5. 可変フレームレート非対応
6. 内部形式(YC48)がplanarでなく、packed。AVX2のshuffleの残念仕様(なぜか128bit×2のshuffleしかできない)と相まってSIMD化がいろいろつらい。
まあ1以外はいくらでも誤魔化しが効く。4Kはまあ、LargeAddressAwareで4GBの仮想メモリ空間が使えるのを前提とすれば、設定でメモリをケチればなんとかなる範囲だと思うので、1も8Kを扱わない限り、問題にはならないだろう。ただ、エンコーダとかは外部プロセスにしていかないと厳しいかもしれない。
その他
勝手にダウンロードリンク集を更新した。
Aviutl関連
・waifu2xを追加。
・透過性ロゴフィルタ (改)を追加。
・シークバー+、ジャンプバー＋、入力優先度変更 βを追加。
その他
・StaxRip、 つんでれんこ、 夏蓮根追加。
・BlueskyFRC、DXVA Checker、BitrateViewer、DirectShow Filter Tool、GraphEditなど追加。
自分で作ったものとか
delogo
今年はまずdelogoの拡張とかした。
個人的には、これまでエンコード対象に対してプロファイルを選んでから、さらにそのファイルに合わせてロゴを選択する手間がかかっていたが、ロゴが自動的に選択されるようになり、かなり便利だった。
録画後に自動的に
・SCRename
・インデックス生成 (.gl, .lwi)
・音声分離 (ts2aac)
などをやらせるようにしておき、Aviutlのプロファイルに
・インタレ解除の自動フィールドシフト
・透過性ロゴ(自動ロゴ選択)
・クロップ
・リサイズ(fullHD固定)
・x265guiExの設定
を記憶させておけば、あとは手動でカット編集後、プロファイルを選択するだけでエンコード実行まで持ち込むことができ、手動で操作する部分が最小限となり、非常に便利になった。
自動化によって手間を削減するのはなかなか楽しいし、やりがいがある。
自動フィールドシフト (afs)
今年は自動フィールドシフトを速くするネタを思いつけなかった。誠に遺憾である。
まあこれまでも結構速くしたのだけど、24pへのインタレ解除はこれしか使わないので、もっと速くしていきたい。とはいっても演算律速というわけではなくメモリ律速なので、できることが限られているのが辛い。
QSVEnc
QSVはハードウェアエンコーダの中でも高速で、画質もまあ、比較的よいほう。
今年の大半はQSVEncCのavqsv周りをやっていた気がする。QSVでデコード→Vpp→エンコードまでを一貫して行うavqsvモードは、QSV高速化のためには必須であり、やっとQSVEncCが他のQSVエンコーダと比べて遅いという嘆かわしい状態を解決できたと思う。高速化とは良いものだ。まあ、最終的にはメモリ速度律速なのだけど…。
デコードは結構入力ファイルに左右されるので、難しい部分もあって、入力ファイル次第で予期せぬ動作をしたりした。このあたり、コメントで報告いただいたり、海外の方からも報告をもらったりして、全部OKというのは難しいけれど、それでも最初のころよりもよくなったと思うし、少しづつよくしていきたいと思う。
例の実験で、個人的な目標は達成できた。つまり、カット編集をAviutlから行って、GUIで設定して、それでQSVトランスコードしたい、ということ。カット編集の実装は結構面倒だったのだけど、比較的初期の段階からカット編集(--trim)を含めて実装していてよかった。
まあ、一方で、最近QSVはffmpegに取り込まれてきているので、QSVEncCの存在価値は微妙なのかもしれない。
NVEnc
HW HEVCエンコーダとか、いろいろ追加した。あとはQSVEncのavqsvのようなものをこっちにも持ち込んだりとか。NVENCもQSVほどではないが、結構高速でいい感じ。特徴としては、YUV4:4:4なH.264がいけるところだろうか。このあたりは、さすがにゲームのリアルタイム転送を主目的としてることはあるかな、って思う。あとは、もう少し圧縮率が良くなるといいけど。
VCEEnc
なんというか、速度面でも画質面でもQSV/NVEncと差があって、あまりやる気がしないです。…Radeonをお持ちの皆さんには大変申し訳ありません。
結構いろいろ勉強になった。
その1. 並列化は重要だ & やはりN3150のシングルスレッドは遅い
パイプライン並列化を実装したやつ。音声エンコードも、これだけ高速に回そうとすると、それなりにCPUパワーを喰うみたい。ほんとはもっと並列化したほうがいい?
その2. 履歴を残すことは重要だ
問題を指摘いただき、履歴のおかげですぐ治せた。ご指摘ありがとうございました。
その3. CentOSとか
まあLinuxには疎いので、いろいろ勉強になった。gccのビルドとか。開発環境(eclipse)の導入とか。C++11とか。あと、なんかmingwよりconfigureとかbuildとか異常に速い。
その4. libavcodec/libavformatなど
なんかlibavcodec/libavformatのAPIがすこしわかるようになった。ただ問題は、デバッグ(変数の中身見る)が結構面倒なこと。VCでビルドするのも面倒だし、eclipse cdt + mingwだとなんかうまくいかなかたりするしで、最初はいちいちprintfとかしていたのだけど、最終的には結局linuxでeclipse cdtを使ってデバッグしていた。これが一番よいかもしれない。
終わりに
という感じで、振り返るといろいろ自動化・高速化できたので、来年も時間があればこの調子でもっとできればいいなと。まあでもさしあたりはQSVEncCの機能強化かなあ…。
さて、今年も、不具合を量産いたしました…。こんなところにも発見してしまった…QSVEncはうまく動かないらしいです。なんかすみません…。
発見するのが難しいものもある一方で、まことにアホな不具合もあったと思います。
そんななか、多くの方々に不具合のご指摘・ご意見をいただいたり調査いただいたりと、ご協力いただきましてありがとうございました。
来年も、可能な範囲で不具合修正は早めに対応していきたいと思います。
動画関連ソフト
x265
今年もだいぶ高速化されてうれしい限り。
lwinput.aui
ついにQSVデコードが追加された。特にH.264デコードでは、CPU使用率の低減という効果があると思う。
透過性ロゴ (改)
ロゴ消しについて、フェードやノイズ除去を適応的に行うという点で、フェードを手動で設定する必要がなくなりとても素晴らしい。
waifu2x
なんかめちゃくちゃ流行っていた。多すぎる派生版はこのあたりにまとめてくださっている方がいる。Aviutl向けには、こちらにあるものがよいと思う。
最初途方もなく重かったので、高速化を多くの方が取り組まれていて、いかに高速化するか、非常に面白かった。まあ基本はconvolutionで、演算自体は非常に簡単なのに、普通に書いたら、メモリロードが多すぎて遅くなるやつだ。この傾向はちょっと行列積に似ている気がする。
高速化の方法をまとめてくださっている方がいらっしゃって、非常に面白く、大いに勉強になる。
最内ループからはじめる深層学習
…読んでみると、なるほど、とは思うのだけど、わたしには技術力(と気合?)が足りないので、こんなコードを組める気がしない…。本当にすごいと思う。
Aviutl
今年はあまり更新がなかった。
Aviutl後継?
Aviutlの後継に関するうわさを聞いた。まあ、それはそれとして、じゃあわたしがなんでAviutlを使うのかという話。
Aviutlを使う理由/Aviutlが素晴らしい理由
0. Windowsで動作する (前提条件)
1. 日本語のUIである (重要)
2. 自動フィールドシフトがある (重要)
3. 比較的通常のマウス操作で直観的に操作しやすい (変わったインターフェースでない、GUI中心のソフトである)
4. エンコードに必要なその他のプラグインがそろっている
aacfaw.aui, delogo.auf, chapter.auf, cutedit.auf, m2v.aui, lwinput.auiなど
5. 困ったらプラグインにより自由に拡張できる。AviutlのAPIに加え、Win32APIを駆使すれば本当にいろいろできる。
6. 内部形式がYUV444。→ 色差の劣化が少ない
7. 内部形式が12bitなので、8bitや10bit出力には十分な精度、一方で16bitではないので演算コストが低い(16bitだったら、桁あふれを防ぐため、32bitでの演算が必須となり、SIMD演算のパフォーマンスが大幅に劣化する)
まあ使い始めた理由はほとんど0～3で、まあそうじゃなかったら使ってなかったかもしれない。
Aviutl本体はもちろん、これまで多くの方々が作ってくださったプラグインが豊富にあるため、Aviutl全体として本当に多くの機能が実現されていて、とても素晴らしいと思う。
Aviutlの困ったところ
1. メモリ4GB制限 (32bitプロセス)
2. Unicode非対応
3. 多重音声非対応
4. プラグイン多重使用非対応
5. 可変フレームレート非対応
6. 内部形式(YC48)がplanarでなく、packed。AVX2のshuffleの残念仕様(なぜか128bit×2のshuffleしかできない)と相まってSIMD化がいろいろつらい。
まあ1以外はいくらでも誤魔化しが効く。4Kはまあ、LargeAddressAwareで4GBの仮想メモリ空間が使えるのを前提とすれば、設定でメモリをケチればなんとかなる範囲だと思うので、1も8Kを扱わない限り、問題にはならないだろう。ただ、エンコーダとかは外部プロセスにしていかないと厳しいかもしれない。
その他
勝手にダウンロードリンク集を更新した。
Aviutl関連
・waifu2xを追加。
・透過性ロゴフィルタ (改)を追加。
・シークバー+、ジャンプバー＋、入力優先度変更 βを追加。
その他
・StaxRip、 つんでれんこ、 夏蓮根追加。
・BlueskyFRC、DXVA Checker、BitrateViewer、DirectShow Filter Tool、GraphEditなど追加。
自分で作ったものとか
delogo
今年はまずdelogoの拡張とかした。
個人的には、これまでエンコード対象に対してプロファイルを選んでから、さらにそのファイルに合わせてロゴを選択する手間がかかっていたが、ロゴが自動的に選択されるようになり、かなり便利だった。
録画後に自動的に
・SCRename
・インデックス生成 (.gl, .lwi)
・音声分離 (ts2aac)
などをやらせるようにしておき、Aviutlのプロファイルに
・インタレ解除の自動フィールドシフト
・透過性ロゴ(自動ロゴ選択)
・クロップ
・リサイズ(fullHD固定)
・x265guiExの設定
を記憶させておけば、あとは手動でカット編集後、プロファイルを選択するだけでエンコード実行まで持ち込むことができ、手動で操作する部分が最小限となり、非常に便利になった。
自動化によって手間を削減するのはなかなか楽しいし、やりがいがある。
自動フィールドシフト (afs)
今年は自動フィールドシフトを速くするネタを思いつけなかった。誠に遺憾である。
まあこれまでも結構速くしたのだけど、24pへのインタレ解除はこれしか使わないので、もっと速くしていきたい。とはいっても演算律速というわけではなくメモリ律速なので、できることが限られているのが辛い。
QSVEnc
QSVはハードウェアエンコーダの中でも高速で、画質もまあ、比較的よいほう。
今年の大半はQSVEncCのavqsv周りをやっていた気がする。QSVでデコード→Vpp→エンコードまでを一貫して行うavqsvモードは、QSV高速化のためには必須であり、やっとQSVEncCが他のQSVエンコーダと比べて遅いという嘆かわしい状態を解決できたと思う。高速化とは良いものだ。まあ、最終的にはメモリ速度律速なのだけど…。
デコードは結構入力ファイルに左右されるので、難しい部分もあって、入力ファイル次第で予期せぬ動作をしたりした。このあたり、コメントで報告いただいたり、海外の方からも報告をもらったりして、全部OKというのは難しいけれど、それでも最初のころよりもよくなったと思うし、少しづつよくしていきたいと思う。
例の実験で、個人的な目標は達成できた。つまり、カット編集をAviutlから行って、GUIで設定して、それでQSVトランスコードしたい、ということ。カット編集の実装は結構面倒だったのだけど、比較的初期の段階からカット編集(--trim)を含めて実装していてよかった。
まあ、一方で、最近QSVはffmpegに取り込まれてきているので、QSVEncCの存在価値は微妙なのかもしれない。
NVEnc
HW HEVCエンコーダとか、いろいろ追加した。あとはQSVEncのavqsvのようなものをこっちにも持ち込んだりとか。NVENCもQSVほどではないが、結構高速でいい感じ。特徴としては、YUV4:4:4なH.264がいけるところだろうか。このあたりは、さすがにゲームのリアルタイム転送を主目的としてることはあるかな、って思う。あとは、もう少し圧縮率が良くなるといいけど。
VCEEnc
なんというか、速度面でも画質面でもQSV/NVEncと差があって、あまりやる気がしないです。…Radeonをお持ちの皆さんには大変申し訳ありません。
結構いろいろ勉強になった。
その1. 並列化は重要だ & やはりN3150のシングルスレッドは遅い
パイプライン並列化を実装したやつ。音声エンコードも、これだけ高速に回そうとすると、それなりにCPUパワーを喰うみたい。ほんとはもっと並列化したほうがいい?
その2. 履歴を残すことは重要だ
問題を指摘いただき、履歴のおかげですぐ治せた。ご指摘ありがとうございました。
その3. CentOSとか
まあLinuxには疎いので、いろいろ勉強になった。gccのビルドとか。開発環境(eclipse)の導入とか。C++11とか。あと、なんかmingwよりconfigureとかbuildとか異常に速い。
その4. libavcodec/libavformatなど
なんかlibavcodec/libavformatのAPIがすこしわかるようになった。ただ問題は、デバッグ(変数の中身見る)が結構面倒なこと。VCでビルドするのも面倒だし、eclipse cdt + mingwだとなんかうまくいかなかたりするしで、最初はいちいちprintfとかしていたのだけど、最終的には結局linuxでeclipse cdtを使ってデバッグしていた。これが一番よいかもしれない。
終わりに
という感じで、振り返るといろいろ自動化・高速化できたので、来年も時間があればこの調子でもっとできればいいなと。まあでもさしあたりはQSVEncCの機能強化かなあ…。
さて、今年も、不具合を量産いたしました…。こんなところにも発見してしまった…QSVEncはうまく動かないらしいです。なんかすみません…。
発見するのが難しいものもある一方で、まことにアホな不具合もあったと思います。
そんななか、多くの方々に不具合のご指摘・ご意見をいただいたり調査いただいたりと、ご協力いただきましてありがとうございました。
来年も、可能な範囲で不具合修正は早めに対応していきたいと思います。
スポンサーサイト
