使い方
以下の並び替えスクリプトをコピペ(改行は気にせず)でブックマーク登録して https://www.nicovideo.jp/watch/sm44957778 でそのブックマークを起動するか開発者ツールのコンソールを使う
この手のコードや手法(ブックマークレット)に関して、悪意のあるコードを潜ませたアクターが言葉巧みに他人に起動させてそのサイトのクッキーやアカウントを奪おうとすること (ソーシャルエンジニアリング)もあるので注意。
余談
ニコニコ側のエンコードのせいかこちら側でエンコードするときにビットレートが低すぎたせいかだいぶ粗くなってしまった
適当にシャッフルしたが負荷とか考えると再考の余地あり
主だった目的は削除テストだがここまでしてホモビをニコニコで見る必要があるのかは分からない。
2025-05-11にこのスクリプトを投稿して数時間後、putImageData()/getImageData()のパフォーマンスが落ちる現象が起こる。投稿時はなんの問題も無かったのでニコニコのアップデートが影響したと思われるが根本的な原因は不明。調べると元々それらの関数はパフォーマンスに良くなかったらしく、drawImage()で代用した。
それとは別に最初に投稿したスクリプトの並び替えの方法が無駄が多かったので改善。
このページの一番最後にffmpegでエンコードした際のコマンドラインがあります
2025-05-13追記: どうやらffmpegのswaprectのバグか仕様で画質がだいぶ粗くなってしまうようである。cropで50px以下を受け付けないことを考慮すると低pxだとバグるとガタイで分析?現在気が向いたときに試行錯誤中。cropとoverlayで無理に重ね合わせる試みは画質は改善したものの部分的に正確でない出力が出てしまったりする。
2025-05-20追記:クロマサブサンプリングWikipediaとやらが原因か一因で境界で滲むらしい。(アーティファクトと言うらしい)(wikipediaの画像参照)
動画編集ソフトでロスレスを出力→ffmpegやhandbrakeで色々設定弄ってエンコード→動画編集ソフトでアーティファクトがないかを確認という流れを何度も試し分かったのはyuv422(p)であれば(適切なビットレートやcrf下で)このアーティファクトは出なくなるがyuv420(p)だと恐らくどう設定しても出てしまうようである。デブロッキングフィルターを無効化してエンコードもしてみたがどうやら効果は無いようだ。
クロマサブサンプリングが4x2なら偶数の縦解像度で分割したらアーティファクトは出ないはずでは?(検証のときは元動画を縦16や32で分割している)などまだ気になる部分はあるがh264の何らかの仕様なのだろう。ニコニコがh264の4:2:0しか対応していない(というかfirefoxがh264の4:2:2や4:4:4に対応していないのが理由なのかもしれない。vp9の4:4:4であれば再生できるが)以上このアーティファクトが出ない動画をあげるのは厳しそうだ。
気が向いたときにh264の仕様を深堀りして再挑戦したりするかもしれない。
ちなみにffmpegは-pix_fmt yuv422pにしてswaprectをしてもアーティファクトは出る謎の仕様を持つようです。この手のエンコーダー特有の仕様も面倒ですね…
2025-05-23追記: YUViewのおかげで分かったがどうやら多くのブラウザや動画プレイヤーの仕様でyuv420pだとサブサンプリングされたピクセルをアップサンプリングする際Bilinear等で処理をして視覚的に滑らかにするようだ。(Chroma Interpolation)
エンコード時の処理に加え、このChroma Interpolationもこのスクリプトでアーティファクトが生まれる一因だった。計算すれば元のYUVに戻せる。
が、結局のところニコニコ側の再エンコードでアーティファクトが生まれるのは避けられないようだ。