Microsoft Edge は独自の HTML レンダリングエンジンを捨てて、Google Chrome と同様 Blink という HTML レンダリングエンジンに切り替えました(2020 年くらい)。という経緯を知っていたので、今まで Edge と Chrome は大差ないと思っていたのですが、Alt+Tab を押したときの挙動が違うことに気づきました。
Windows 10 は Alt+Tab で Edge のタブ切り替えができる
Edge のウインドウは 1つしかありませんが、Alt+Tab を押すと Edge が 2つ表示され、Edge のタブが Windows のウインドウのように特別扱いされることがわかります。普段 Edge を使わないため全くこの機能を知りませんでした。また Windows 10 の設定ウインドウを見ていて、この機能を OFF にできることも知りました。
Edge 以外のブラウザ、ファイル管理、ターミナルなど、タブ機能を持ったアプリはそこそこ多いと思いますが、Edge のタブだけ Alt+Tab で切り替え、他のタブ機能は切り替えできない、という一貫性のなさは混乱しますが……。ウケが良かったらそのうち OS の標準機能になるかもしれませんね。
興味本位で調べていたんですが、ニコニコ動画の 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 に準拠して扱いを楽にしておき、鍵だけ規格から外した扱いで実装してある、なかなか面白いバランスでした。商用サービスの設計を垣間見た気がします。なるほどなあ。
鍵の取得方法も調べましたが詳しくは述べません。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 から転記しておくことにした。色々とマージ&加筆修正。
だいぶ周回遅れですが、リコリス・リコイルの最終回を見てました。最終回に限らず銃撃アクションはどの回も良かったな〜と思います。設定はイマイチ良くわからないですけど、あまり気にしても仕方ないです。それはさておき。ニコニコ動画は、
があって、有料版はちょっと変わってるらしいので、試しに契約してみました。サブスクリプション方式でした、月額 440円だそうです。
現在のニコニコ動画の配信方式は HLS(HTTP Live Streaming, 規格は RFC8216 にて規定)といいまして、MPEG2-TS ファイルを細かく(3〜10秒程度)分割して、クライアントから再生要求された位置から順に送るだけのシンプルな方式です。MPEG2-TS の弱点はインデックスなどの情報が一切なくてサーチが大変なことですが、あらかじめ分割しているため苦労してサーチをする必要がありません。
ちなみにリコリス・リコイルの無料放送版の場合、コーデックは見ての通りで Full HD じゃないです……。有料版でも HD 720p ですから、画質が気になる方にはイマイチかもしれません。他のアニメも同じなのでしょうか?調べていないのでわかりませんけど。
HLS では *.m3u8 というプレイリストも一緒に送られてきて、そこに TS ファイル名が全て載っています。プレイリストにある TS を順番にダウンロードし、単純連結するだけで動画全体の TS ファイルが引っこ抜けます。これはセキュリティホールとかではなく元々 HLS はこういう仕様です。
有料版も同様に HLS で配信されていますが AES-128-CBC 暗号化されていて、TS ファイルを引っこ抜いても再生できません。しかしなぜか無料版は暗号化されておらず TS ファイルを引っこ抜くと再生できてしまいます。設定ミス……?わざと?まあどっちでもいいですけど。
キャプチャだとわかりにくいかもしれませんが、右下に「ニコニコ」という透かしが入っています。有料版は入っていません。
TS ファイルのサイズを比較(AES-128-CBC 暗号化でファイルサイズは変化しないので、この比較には意味がある)してみましょうか。使ったのはリコリス・リコイル最終話です。
有料版(d アニメ支店版)は 100MB くらい小さいです。無料版は先ほど説明したように右下に透かしを入れるために再エンコードしていると思いますが、再エンコードだけでは説明できないほどサイズが違います。なんで?と思って調べてみたら、どうやら、
になっているようです。オープニングのエレベータが降りていくシーンが非常にわかりやすいです。高速(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 から転記しておくことにした。色々と加筆修正。
< | 2022 | > | ||||
<< | < | 10 | > | >> | ||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
- | - | - | - | - | - | 1 |
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 | 31 | - | - | - | - | - |
合計:
本日:
管理者: Katsuhiro Suzuki(katsuhiro( a t )katsuster.net)
This is Simple Diary 1.0
Copyright(C) Katsuhiro Suzuki 2006-2021.
Powered by PHP 5.2.17.
using GD bundled (2.0.34 compatible)(png support.)