Darkside（https対応しました）

　scikit-video 経由で FFmpeg を読み出すと、画像が壊れているだけでなく極めて遅いという大問題もある。恐らく、GPU を使ってくれない。しかし、OpenCV 標準だと、融通が効かない。圧縮 CODEC は圧縮し過ぎて画質が論外。非圧縮 CODEC は巨大過ぎる。
　使える fourcc は無いのか？
　探してみる。

　I420 は非圧縮だが、ファイルが巨大なことを除けば出力結果は適切である。１分あたり１００ギガというサイズも、Davinci Resolve が読んでくれるなら十数分までなら使用可能。それだけ巨大なくせして 420 の色情報というのが超絶に不満だが。いちおう最後の手段としてキープしておく。
　片っ端から試すが、OpenCV の使えなさが明らかになるばかり。圧縮 CODEC はどいつもこいつも、圧縮率最大・画質最悪に固定されているかのようだ。圧縮品質を設定することができない。

　以前 Davinci Resolve が落ちたのは、Aviutl が出力した無圧縮ファイルだった。今回は 420 という劣化版なので、落ちないかもしれないと期待。ついでに念のため、ver 18 beta もダウンロードして試すことにする。
　余りにも酷いことに、落ちた。ver.18 beta もだ。
　だが、ここまで酷いバグが放置されているのは謎である。対処方法を調べると、どうやら Davinci Resolve には明記されていない問題があり、無劣化の動画を読むことが出来ないようだ。対策は、画像シーケンスを読ませろ！

　そうだ、OpenCV は動画フレームを画像出力することもできた。正距円筒変換した結果を、連番 png ファイルで出力すれば良い。試すと、I420 に比べて５分の１ぐらいのサイズになった。しかも png だから品質も I420 より上のはず。
　品質と、容量節約。両立できるじゃないの。

　ついでだが OpenCV を C++ から使う方法を調べると、画像イメージを格納すべき型は判明した。しかし、Aviutl 内部で画像イメージを扱う型とは異なる。そのため、せっせと変換しないといけない。この時点で、やはり大幅なオーバーヘッドである。更に、独自変換ならリサイズも同時に行えて、追加で必要な時間はゼロ。いっぽう Aviutl では別プラグインでリサイズするので、これもオーバーヘッド。
　そうすると、無圧縮出力で膨大なディスクスペースが必要であっても、処理時間は明白に独自変換が勝る。
　こうして最終的に、独自変換で行くことにした。
　４分１３秒のクリップで、処理時間を比べてみる。

　正距円筒変換に比べて無視できないほど png 圧縮に時間を要するというのが何ともはや。それでも、Aviutl 改造プラグインを使うより１０倍ぐらい速いので、ようやく現実的な処理時間のワークフローになりそうだ。