Darkside（https対応しました）

　動画の読み書きというインフラ部分は、Python と OpenCV を使うのが簡単に記述できそうだ。
　問題は、読み込み可能な CODEC と、書き出し可能な CODEC が何であるか？

　Aviutl を使う場合、書き出しは選択肢が豊富だが over 8bit で読み込めるのが無圧縮しかないのが困る。
　OpenCV は CineForm が読めたので、Davinci Resolve の出力を CineForm にすることで高品質の引き渡しが可能である。しかし、今度は書き出す時に適切な高画質 CODEC が無い。いや、正確に言えば「無い」のではなく「分からない」。
　エラー出力で ffmpeg うんぬんと出るので、どうやら OpenCV は動画の出力に ffmpeg を下請けに呼び出しているようだ。そこで最新の ffmpeg をダウンロードし、ソースファイルから fourcc の一覧を調べる。その結果、遺憾なことに CineForm には対応していないようだ。
　ならば他に使用可能な、over 8bit の圧縮 CODEC はあるのだろうか？

　候補としては XAVC 10-bit 4:2:2 か Apple ProRes 422 しかない。前者は最大解像度 3840x2160 だし libopenh264 が必要。いちおう libopenh264 を調べると、やはり 3840x2160 までしか対応していないと明記されている。つまり、使えない。
　後者も案の定で、Windows では使えないようだ。
　無圧縮だと、300 ギガバイト超えたあたりで Davinci Resolve が落ちるんだよな。
　品質で妥協すれば mp4v ってことになる。困ったものだ。出口が詰まってしまうから、せっかく CineForm で読み込んでも意味がない。

　そうなると今度は、現状の Aviutl ワークフローを OpenCV で高速化するという策も魅力である。問題は、Aviutl のプラグインから OpenCV を利用できるのかどうか？
　だがこれも、すぐに困難だと気付く。プラグインには画像を配列に格納して渡って来るので、非常に処理し易い。だが、OpenCV を利用する上では画像まるごとを１つの概念として扱うので、配列をその概念に変換せねばならない。その方法は分からないし、分かったとしても処理の無駄が甚だしい。

　どうにもならなくても最悪現状のワークフローは使えるので、試すだけ試してみよう。
　何はともあれ、正距円筒変換ができなければ始まらない。Aviutl のプラグインを VR180 専用で Python + OpenCV に移植する。これは成功し、危惧していたデーターレベルがフル(0-255)の mp4 も、正常に扱えているようだ。しかし、出力は mp4v だと恐ろしく画質が悪い。ほぼ、8x8 のモザイク状態で使い物にならない。
　さすがに OpenCV でこのどうしようもない問題には、既に解決策があるだろうと調べる。scikit-video というのが使えそうだ。FFmpeg をパラメーター指定で呼び出せる。

pip install scikit-video

　Linux では pip ですぐエラー続出するのだが、Windows では文句を言わずに動いてくれる。
　しかし出力された動画ファイルは、無茶苦茶だった。