コグノスケ

ニコニコ動画の暗号化HLSの謎

興味本位で調べていたんですが、ニコニコ動画のHLSの暗号化の仕組みがわかりました。基本的には暗号化HLSと同じです。m3u8ファイルにEXT-X-KEY Tag（仕様は RFC8216 4.3.2.4 EXT-X-KEY にあります）があって、METHOD=AES-128（暗号化方式がaes-128-cbc方式）、鍵のありかを示すURI、IV（Initial Vector）が書いてあるタイプです。他のAttributesは使っていません。

暗号化自体はaes-128-cbcですが、復号用の鍵の扱いはHLSの規格と異なっておりURIに示されたファイルを使っても復号できません。暗号化の仕組みを見た限り、コスト度外視でガチガチにガードするDRMというより、ffmpegなどのHLS再生に対応した有名ツールを使ってお手軽ダウンロードされなければヨシ！という作りに見えます。HLS規格から大改造すればするほど既存ライブラリが使えなくなったり、クライアントもサーバーも作るのが大変になるからではないかと推測しています。

AESは鍵さえわからなくすれば復号できませんから、基本的にはHLSに準拠して扱いを楽にしておき、鍵だけ規格から外した扱いで実装してある、なかなか面白いバランスでした。商用サービスの設計を垣間見た気がします。なるほどなあ。

DRM解除してはいけません

鍵の取得方法も調べましたが詳しくは述べません。RC2から（※）のニコ動ユーザーとして、これからも末永く利用したいので、ニコ動の不利益になることは本意じゃないです。ニコ動がんばって。応援してるぜー。

改正著作権法ではDRM回避行為そのものも違法（今は罰則はありませんが……）です。回避装置の譲渡には懲役刑や罰金刑といった刑事罰があります（参考: 私的リッピングも違法！？いよいよ改正著作権法が一部施行 - 週刊アスキー）。

「再現可能なレベルの回避手段の解説」＝「回避装置の譲渡（懲役刑や罰金刑といった刑事罰がある）」とみなされて当然だと思うので、私は絶対にDRM解除方法は公には書きません（方法を知っても他人に教えません）。皆様もパズルの答えの感覚で「DRMの解き方がわかった！方法はこうしてこう！」ってその辺に書かないようにしましょう。

（※）ニコニコ動画の変遷を見るとRC2は2007年〜2008年頃だから約15年経ちましたか。早いもんですね。

ニコニコ動画の無料版がカクついている理由

ニコニコ動画の24p → 30pの変換の仕方と、テレビなどが行っている24p → 60iの変換の仕方（2-3プルダウン、3-2プルダウンとも呼ぶ）を図示してみました。もうちょっとわかりやすくしたかったけど……絵心が足りませんでした。

24pから30p, 60i（2-3プルダウン）, 60pへの変換

24p → 30p変換は非常にシンプルで、24pフレームの表示すべき時間（PTS: Presentation Timestamp）に到達していたら表示、まだだったら前と同じフレームをリピート、という非常に単純な処理です。利点は画が自然なことで、欠点はカクつくことです。縦や横に一定速度でスクロールするシーンは進んで止まってを繰り返すためガクガクします。

2-3プルダウンは若干ややこしく、インターレース（偶数ラインと奇数ラインが交互に更新される）の特徴を使います。60iの3コマ目（5-6フィールド）に24pの2, 3コマ目の偶数、奇数ラインを混合した画を出します。4コマ目（7-8フィールド）は24pの3, 4コマ目の混合です。利点はカクつきが少ないことで、欠点は画が不自然になることです。例えば24pの2コマ目にリンゴ、3コマ目に突然オレンジが映る場合、60iの3コマ目はリンゴとオレンジが縞々に合わさったキメラ画像になります。

このように2-3プルダウンは良くできているものの完全無欠ではないので、テレビによって扱われ方が違います。最近のテレビであればおそらく画像が24pだと検知すると自動的に2-3プルダウンが発動すると思いますけど、製品によっては「映画モード」とかに変えないと発動しないかもしれません……。

最後に24p → 60p変換ですが、何の工夫もないのにほぼカクつきなしで不自然な画もありません。24pは下手に30pとか60iに変換せず、60pで殴りなさいという悲しい結論ですね。細かく見れば2コマ、3コマ、2コマ、3コマ……と繰り返されるので1/120秒の揺らぎがあります。でも人間にはわからないと思います。たぶん。とりあえず私はさっぱりわかりません。

メモ: 技術系の話はFacebookから転記しておくことにした。色々とマージ＆加筆修正。

ニコニコ動画の動画は2種類ある

だいぶ周回遅れですが、リコリス・リコイルの最終回を見てました。最終回に限らず銃撃アクションはどの回も良かったな〜と思います。設定はイマイチ良くわからないですけど、あまり気にしても仕方ないです。それはさておき。ニコニコ動画は、

• 無料版: 期間限定公開
• 有料版（dアニメ支店）

があって、有料版はちょっと変わってるらしいので、試しに契約してみました。サブスクリプション方式でした、月額440円だそうです。

ニコニコ動画の動画配信方式の概要

現在のニコニコ動画の配信方式はHLS（HTTP Live Streaming, 規格は RFC8216 にて規定）といいまして、MPEG2-TSファイルを細かく（3〜10秒程度）分割して、クライアントから再生要求された位置から順に送るだけのシンプルな方式です。MPEG2-TSの弱点はインデックスなどの情報が一切なくてサーチが大変なことですが、あらかじめ分割しているため苦労してサーチをする必要がありません。

ちなみにリコリス・リコイルの無料放送版の場合、コーデックは見ての通りでFull HDじゃないです……。有料版でもHD 720pですから、画質が気になる方にはイマイチかもしれません。他のアニメも同じなのでしょうか？調べていないのでわかりませんけど。

• 動画: H.264 HD (1280x720)
• 音声: AAC 48kHz

HLSではプレイリスト（ファイル名が*.m3u8）も一緒に送られてきて、リストにTSファイル名が全て載っています。プレイリストにあるTSを順番にダウンロードし、単純連結するだけで動画全体のTSファイルが引っこ抜けます。これはセキュリティホールとかではなく元々HLSはこういう仕様です。

無料版と有料版の配信方式はちょっと違う

有料版も同様にHLSで配信されていますがAES-128-CBC暗号化されていて、TSファイルを引っこ抜いても再生できません。しかしなぜか無料版は暗号化されておらずTSファイルを引っこ抜くと再生できてしまいます。設定ミス……？わざと？まあどっちでもいいですけど。

無料放送版に入っているニコニコ動画の透かし

キャプチャだとわかりにくいかもしれませんが、右下に「ニコニコ」の透かしが入っています。有料版は入っていません。

無料版と有料版は動画も違う

TSファイルのサイズを比較（AES-128-CBC暗号化でファイルサイズは変化しないので、この比較には意味がある）してみましょうか。使ったのはリコリス・リコイル最終話です。

• 無料版: 377MB
• 有料版: 296MB

有料版（dアニメ支店版）は100MBくらい小さいです。無料版は先ほど説明したように右下に透かしを入れるために再エンコードしていると思いますが、再エンコードだけでは説明できないほどサイズが違います。なんで？と思って調べてみたら、どうやら、

• 無料版: 30fps
• 有料版: 24fps

になっているようです。オープニングのエレベータが降りていくシーンが非常にわかりやすいです。高速（120fpsとか）で動画が撮れるカメラを使うと、無料版は5コマに1回、画が止まることがわかります。

有料版（24fps）が
1 2 3 4 5 6 7 8
このような出方だとして、無料版（30fps）は
1 2 3 4 4 5 6 7 8 8
みたいな出方をします。

意図通りか間違えたか知りませんが、無料版だけ30fpsに変換しているためファイルサイズがやたらデカいようで、暗号化もされていません。どちらかといえば無料版の方が不思議な作りですね。

メモ: 技術系の話はFacebookから転記しておくことにした。色々と加筆修正。

ゼルダのボム袋

ニンテンドーのポイントが期限切れになるぞよ、とメールが来ていたのでゼルダの伝説スカイウォードソードに出てくるボム袋を模した巾着をもらいました。思っていたよりでかい。

ゼルダの伝説、ボム袋風の巾着

ゼルダの伝説はほとんどやったことがなくて、家に届いた巾着を見ても何の模様かわからなかったのですが、奥さんに見せたら一発で「あ！ボム袋だ！」って気づいてました。ゲーム画面のキャプチャを観ると思っていたより再現度が高いです（ゲームのボム袋の方がもう少し背が低いくらい）。良いですね。

なぜかシューティングの練習で使うフロンガス缶のサイズと、この巾着のサイズが超ぴったりでした。フロンガス缶はそんなに種類があるわけじゃない（マルイ、レイラックス、サンダーシュート、ウッドランドがメジャーどころ？）し、同じ種類のガス缶を使っている人も多くて紛らわしいので、こういう個性的＆コンパクトな袋はありがたいです。

メモ: 技術系？の話はFacebookから転記しておくことにした。色々と加筆修正。

Windows PCの画面ロックを妨害（Windows API版）

目次: Windows

先日（2022年9月19日の日記参照）はJavaScriptと画面起動ロックAPI（Screen Wake Lock API）にてWindows PCの画面ロックを妨害する方法を紹介しました。

今回はWindows API（SetThreadExecutionState）を使って同様の機能を実現します。詳細はMicrosoftのAPIドキュメント（SetThreadExecutionState function (winbase.h) - Microsoft Learn）と、スリープに関する日本語の解説（システム スリープ条件 - Microsoft Learn）が参考になります。

そういえばWindows APIのドキュメント、今の名前はMicrosoft Learnになっていますね。昔はMSDN OnlineとかMicrosoft Docsとか呼ばれてた気がしますが、統合されて消えてしまったのかな……？

さておきコードはこんな感じです。簡単すぎるのでわざわざ載せるまでもないですけども。

#include <iostream>
#include <windows.h>
#include <winbase.h>

int main()
{
    EXECUTION_STATE r;

    r = SetThreadExecutionState(ES_CONTINUOUS | ES_AWAYMODE_REQUIRED);
    if (r == NULL) {
        std::cout << "failed!" << std::endl;
    }

    std::string hoge;

    std::cin >> hoge;

    return 0;
}

アプリケーション実行中にpowercfgでチェックすると、こんな風になるはずです。なおpowercfgを実行するには管理者権限でコマンドプロンプトを起動する必要があります。アプリケーション名は適当に読み替えてください。

C:\Windows\system32>powercfg /requests
DISPLAY:
なし。

SYSTEM:
なし。

AWAYMODE:
[PROCESS] \Device\HarddiskVolume3\dat\projects\c\ConsoleApplication1\x64\Debug\ConsoleApplication1.exe

実行:
なし。

PERFBOOST:
なし。

ACTIVELOCKSCREEN:
なし。

画面起動ロックAPIはDISPLAYモードを要求していましたが、今回はAWAYMODEを要求しているので違うカテゴリに表示されています。もちろんAPIの引数を適切に変更すればDISPLAYも要求できます。

他の利用者

画面ロックの妨害機能のユーザーは意外と多いです。前回挙げたPowerPointの他に、Teamsのような会議アプリケーション、メディアプレーヤーなども使っているようです。個人的に意外だったものとしてはセットアッププログラムです。

例えば、下記はVisual Studioのセットアップ中にpowercfgを実行した結果です。

C:\Windows\system32>powercfg /requests
DISPLAY:
なし。

SYSTEM:
なし。

AWAYMODE:
なし。

実行:
[PROCESS] \Device\HarddiskVolume3\Program Files (x86)\Microsoft Visual Studio\Installer\setup.exe
Visual Studioインストーラー

PERFBOOST:
なし。

ACTIVELOCKSCREEN:
なし。

普通はセットアップ中にスリープされることなんて想定していませんから、セットアップがエラーになる可能性があります。不都合が起きなかったとしても、スリープ中はセットアップが進みません。と、考えると時間がかかるセットアップ中にスリープを妨害するのは筋が通ってますね。