前書き込みいくつかはここから >>159654

>NicoCache26 >8
>>159670
>フォルダまでは作られるけど、同じく再生は出来ず。
この症状は再現出来ないのだけれども、品質モードを「自動」にしていると再生出来ないことに気付いたので、そっちを先になんとかします。
「自動」でも再生出来るはずだったけれど、動かないということはコーディングに何か考慮漏れがありそうなので。
（生放送も考慮に入れてないけど後回し）

>NicoCache26 >9
>最初のロード「no cache found: smxxxx」の後に「通信中断/.../Ranged request: video/01.cmfv...」が表示され、
>キャッシュは「nltmp_smxxxx/video/01.cmfv」だけがない状態になる。
こっちだとranged requestとnot modifiedが第1セグメントに対してよく起きる。
でも正常通信も来るから第1セグメントのキャッシュファイルが出来てる。

onTransferEndイベントの時にcompleted引数にfalseが来た時に「通信中断」と表示してました。
completedじゃなくて応答ボディの長さを数えてそれで通信中断したかどうかという判定に変えてみます。(dmc/hls処理はそう書いてあったし)

>>159671
>とりあえず、16の倍数にならないのは01.cmfvの場合がほとんどのようなので、初期の通信が混ざってないかとか検証しようと思ってました。
>しかし、通信が並行しているときの振り分け方とかがどうなっているのかが、全然わからない感じです。
NicoCacheのコードは全体的にイベントドリブンに処理が書いてあります。

Processor継承クラスのonRequestにブラウザからの要求(ブラウザはニコ動に要求しているつもり)がnicocacheに来ます。
だからCmafUseCacheProcessor.javaの動作の開始点はonRequestだけです。
一つのURLにつき一回onRequestが呼び出される感じ。

各Processorを登録しているのはServer.javaのregisterProcessorあたりで、実際にonRequestを呼び出しているのはConnectionManager.javaのentry.getProcessor().onRequest(requestHeader, browser);のあたり。

nicocacheの上流は一つの通信に一つのスレッドを割り当てています。
だから複数の処理が同時に流れてる。
こういう設計だから通信処理1と通信処理2で値を共有したい場合にちょっと回りくどいことをしないといけないです。
この値共有のために作ったのがNLShared.INSTANCE.getDomandCVIManagerという共有オブジェクトとDomandCVIEntry。

onRequestから入ってきた要求を条件分岐してそれが動画セグメントならば、addTransferListenerというコンテンツ受信時に処理を呼び出す機能にCmafUseCacheProcessor内で定義したChunkListenerのインスタンスを登録しています。
以降はその通信でコンテンツを受信したり受信完了した時に登録したcmaf/ChunkListener内のそれぞれの処理が呼び出されます。

cmfvやcmfaに対しては、ひとつの通信につき、ひとつのcmaf/ChunkListenerのインスタンスが割り当てられています。
コンストラクタでdecrypterは初期化されています。

セグメント受信時点でdecryptに必要な情報が揃っていない場合は、情報が揃ってから実行するようにmovieInfo(DomandCVIEntry)に登録しています。
上流がデータを受信し、イベントを発火させ、登録されたイベント処理へ渡します。
cmaf/ChunkListener側はonTransferringでデータの部分を受信して、decrypterに渡します。
転送終了(onTransferEnd)時にdecrypterの終了処理もします。
この時点で渡したデータの量が16の倍数じゃないとエラーします。

つまりは……むずかしいね。
（本当はデバッガーを使った方がよかったんだろうけど）自分はLogger.infoをあっちこっちに仕込んで動作させつつコードを読みました。

>>159674
解説ありがとうございます。なんとなくイメージが掴めてきました。
しかし、Logger.infoの出力を見ながらソースを読んでいると、肝心の動画をながら見してしまうという弊害が。
あと、やはり01.cmfvがこけなければほぼキャッシュができるみたいなので、そこを軸にソースを読んでいこうかなと思ってます。

まとまってないので次バージョンはまだです。

次バージョン用
- 動画品質モードの"360p-lowest"に対応. 内部的にはdmcLowとして扱う.

- 動画品質「自動」で再生出来ない問題を修正. 誤った復号鍵キャッシュを返していた.
NicoCacheを導入すると再生すら出来ないと言っていた人の環境がこれで直るといいな、と。

- 以前の動画もdms(domand)で配信されるようになったっぽい.
dms(domand)対応のついでに追加した、dmc/hlsのキャッシュを利用する機能は開発者の環境では上手く動作しています.


事例:

〜ログ前略〜
-- 応答ボディok: audio/01.cmfa(length:85424)
復号完了前に通信中断: video/01.cmfv. content-length[1023232%16=0] input-count[526684%16=12]
<206 partial content> was responded: video/01.cmfv([bytes 510300-1023231/1023232]), Content-Length:512932
〜ログ後略〜

サイズ(1023232)のうち、最初から526684まで受信した後に、510300から最後までを受信している(bytes rangeは開区間表記).
重複部分はあるがブラウザは全体を取得出来ている.
これを扱えれば通信中断と206でもキャッシュファイルを作れる.

>>159676
シークするとセグメントのダウンロードが中断される(既知)
→レジューム再生をオンにしていると1.cmfvのぶった切りが起きやすくなる
と推測してます。
レジューム再生オフでも206や304が頻発するのはなぜかは分からないけど、
上記事例に対応出来れば1.cmfv(とcmfa)のキャッシュ失敗は減るんじゃないかと考えてます

>肝心の動画をながら見してしまうという弊害が。
そこはほら興味がない短い動画を選ぶだよ
10秒前後のオンラインカジノの動作を検証していると思しき動画とか沢山ある

<NicoCache26-10
<作者さんはExtensions消したいということでしたが。
そうじゃないのです。
NicoCacheの機能を削るにあたってExtensionへの影響を知りたい、という趣旨でした。
例えばニコニコ動画のサーバーはもうswfやflvを送信してこないけれど、NicoCacheの本体にはそれらをハンドルするコードが残っています。
これらを削除すると現役のExtensionが動かなくなってしまうかも知れない。
私自身はnlMovieFetcherが動かなかったこともあってExtensionを使っていないので、状況を教えて欲しいという意味でした。

<nlMovieFetcherは普通に動いてますね。
<あとnlMediaInfoもExtension使っていますね
情報ありがと。
本体の方が落ち着いたら中身見ます。

開発途中版5を出しました。

<- 動画品質「自動」で再生出来ない問題を修正. 誤った復号鍵キャッシュを返していた.
<
<- 動画セグメントが分割されて送信されてくる通信に部分的に対応した. これで「通信中断」で1.cmfvが作られない問題が解決するはず.
これのためにコードを随分変えたのでコーディングミスがあるかも知れません。
一通り動作チェックはしたけどね。

<- 動画品質モードの"360p-lowest"に対応. 内部的にはdmcLowとして扱う.
dcmLowは、economyモードを示すlowとは違い、動画モードの差を表すものです。
dmcLowがtrueである360pは、dcmLowがfalseである360pよりも低画質である。という判定に使われています。

<- キャッシュどころか再生出来ない問題のために復号情報関係(key,iv)のログを出力するようにした. 表示過剰なので開発版の間だけ.
<
<- NicoCacheを使っていると再生開始が遅い重い. 要検証.
復号のハンドリングに何か誤りがある気がするが、あまり複雑なことをしていなくて見当なし。

<- 第一セグメントで問題が起きやすいようなので、第一に対してだけステータスメッセージを増やしました.
<
<- 復号情報取得時の復号処理を別スレッドで実行するように変更.
本当に別スレッドで動いているかどうかは要検証.

<- 昔の動画もdms(domand)で配信されるようになったっぽい.
< dmc/hlsのキャッシュを利用した再生は開発者の環境では上手く動作しています.

<- dmc/hls、一つ前の動画仕様を扱うHlsCachingProcessor.javaから発せられる
< メッセージに"(hls)"を付けました。
<
<- 紛らわしかったのでExtensionに関する質問を訂正しました。Extension機能を削除する予定はありません。

>>159680
誤: dcmLow
正: dmcLow

やっぱりレスが消せない。

開発途中版5で完了したけどエラー出てたので貼り付け。
短めだとでないので長めのを選んで（配信アニメだとでた）。

error: chunkavDir==null
+
java.lang.NullPointerException: Cannot invoke "java.io.File.exists()" because "this.chunkavDir" is null
at dareka.processor.impl.CmafCachingProcessor$ChunkListener.<init>(CmafCachingProcessor.java:1034)
at dareka.processor.impl.CmafCachingProcessor.processChunk(CmafCachingProcessor.java:941)
at dareka.processor.impl.CmafCachingProcessor.onRequest(CmafCachingProcessor.java:219)
at dareka.ConnectionManager.processAPairOfMessages(ConnectionManager.java:328)
at dareka.ConnectionManager.run(ConnectionManager.java:66)
at dareka.Server.handleTlsLoopback(Server.java:343)
at dareka.Main.handleTlsLoopback(Main.java:310)
at dareka.processor.MitmResource.transferTo(MitmResource.java:26)
at dareka.ConnectionManager.useResource(ConnectionManager.java:531)
at dareka.ConnectionManager.processAPairOfMessages(ConnectionManager.java:349)
at dareka.ConnectionManager.run(ConnectionManager.java:66)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:857)

+
failed to process: https://asset.domand.nicovideo.jp/65efceef6864fc306f4826f7/audio/1/audio-aac-192kbps/001.cmfa?session=（削除）&Policy=（削除）&Signature=（削除）&Key-Pair-Id=（削除）&nicocachenl_domandcvikey=（削除）
java.lang.NullPointerException: Cannot invoke "java.io.File.exists()" because "this.chunkavDir" is null
at dareka.processor.impl.CmafCachingProcessor$ChunkListener.<init>(CmafCachingProcessor.java:1034)
at dareka.processor.impl.CmafCachingProcessor.processChunk(CmafCachingProcessor.java:941)
at dareka.processor.impl.CmafCachingProcessor.onRequest(CmafCachingProcessor.java:219)
at dareka.ConnectionManager.processAPairOfMessages(ConnectionManager.java:328)
at dareka.ConnectionManager.run(ConnectionManager.java:66)
at dareka.Server.handleTlsLoopback(Server.java:343)
at dareka.Main.handleTlsLoopback(Main.java:310)
at dareka.processor.MitmResource.transferTo(MitmResource.java:26)
at dareka.ConnectionManager.useResource(ConnectionManager.java:531)
at dareka.ConnectionManager.processAPairOfMessages(ConnectionManager.java:349)
at dareka.ConnectionManager.run(ConnectionManager.java:66)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:857)

いまのところaudio側にだけでる。三桁くりかえしたあとcompletedもでないんだけど、自動リピートで最初に戻ったらusing cacheになって、キャッシュが完了してた。

参考までに。

ゴメン、むやみやたらに開いていったらVideoもAudioもでました。
10個ぐらいの平均はA/Vそれぞれ3回で抜ける感じです。
どれもcompletedは出力されないけど完了はしてます。

あと勿論（削除）はこっちで消した部分です。

nullチェックすり抜けを修正しました。
コーディングミスでした。

>>159683
>>159684
自分が書いたのじゃないメソッドの正常返り値にnullが候補があるのだけど、どういう場合にnullが降ってくるのかよく分かっていないです。
これを理由にエラーすると、セグメントをキャッシュする機会を失うことになるから直さねば。

それとそういえば、threadId動画(/watch/以降が数字である動画URL)に対応していないのを思い出しました。
公式配信ってこの形式のURLであることが多いですがキャッシュが動いたということですかね？

さらにそれと、こっちの環境だとwatch/soXXXのURLもNicoCacheが全く反応しなかったです。まだちゃんと調べてない。

<NicoCache26-22
<ニコ生がTS含めてぐるぐるで見れない。
<追記。
<proxy.pac から*.dmc.nicoを無くしたらニコ生は再生されるようになった。
+231111modでも同じ症状は出ますか。
それらURLをNicoCacheのdms(domand)機能はハンドリングしてないからニコ動側で何か仕様変更が入ったかな。
そうなるとdmc/hls仕様領域のコードを追わないと分からない。
ニコ生はdmc.nicoから配信されているものばかりみたい。

こちらではニコニコ生放送の再生は問題ないです。

生放送じゃない動画も仕様変更されたdmc/hlsで受け取っている人がいて、それが原因で再生出来ない、可能性。

>>159685

watch/so435178xxを開いてみましたが、Caching走りますね。
xxは伏せ字。
----
caching so435178xx
+
-- audio iv: ok
-- video iv: ok
-- video key: ok
-- audio key: ok
-- first segment ok: audio/001.cmfa
-- first segment ok: video/001.cmfv
<304 not modified> was responded: video/001.cmfv
----
Browser側のDevToolでみてもちゃんとすぐ
www.nicovideo.jp/local/url_injection_sys.js
が呼ばれてinjectionできてます。
通信先をみるかぎりnico系のサイトは以下の通り
delivery.domand.nicovideo.jp
asset.domand.nicovideo.jp
common-header.nimg.jp
stella.nicovideo.jp
dcdn.cdn.nimg.jp
dcdn.cdn.nicovideo.jp
img.cdn.nimg.jp
public-api.ch.nicovideo.jp
resource.video.nimg.jp
secure-dcdn.cdn.nimg.jp
nv-comment.nicovideo.jp
nvapi.nicovideo.jp
flapi.nicovideo.jp

あとCompletedでないけどリピートで戻るとUsingになる場合、
nvapi.nicovideo.jp/v1/watch/so（削除）/access-rights/hls?actionTrackId=（削除）
がリピート時にプリフライトリクエスト（201）の後のPOSTに400かえってきてますね。
その後
www.nicovideo.jp/api/watch/v3/so（削除）?_frontendId=6&_frontendVersion=0&actionTrackId=（削除）&skips=harmful&additionals=pcWatchPage%2Cexternal%2Cmarquee%2Cseries&isContinueWatching=true&i18nLanguage=ja-jp&t=（削除）
リクエストして再度
nvapi.nicovideo.jp/v1/watch/so（削除）/access-rights/hls?actionTrackId=（削除）
でCreated（201）が返ってきて後はlocalのm3u8呼んでCacheからって感じ。

>>159685
ステータス206、対応ありがとうございます。
私の環境では、ほぼ撮り損ねがなくなった感じです。

だんだんコードが読めてきて、206対応はdecryptを後回しにしないとダメそうだなぁと思っていたところでした。

ところで、「}」の後ろに「;」をつけるのは癖ですか？　実害はないと思いますが、普通付けないなと思ったので。

>>159683
うちでも、開発途中版6で出たので調べてみました。
開発途中版3あたりでキャッシュ失敗（1.cmfvだけキャッシュ失敗したやつ）した動画をそのまま再度見ようとしたときにも、起きるようです。
挙動的には、

1. 1.cmfvがうまくキャッシュできる
2. キャッシュが完成したので、ディレクトリ名からnltmp_がなくなる
3. NicoCacheがnltmp_のディレクトリにアクセスしようとして例外が発生している（？）
4. NicoCacheからの応答が止まるので、動画プレイヤーがリトライを行うと、キャッシュ再生に切り替わって続きが再生される

のようです。
ちなみに、

1. 完成したキャッシュのディレクトリ名に「nltmp_」をつける
2. キャッシュディレクトリの「video/1.cmfv」を削除する
3. 該当動画を再生する

で再現してます。

なお、キャッシュとしては完成するようで、その後のキャッシュ再生は成功しています。

>>159688
>ところで、「}」の後ろに「;」をつけるのは癖ですか？　実害はないと思いますが、普通付けないなと思ったので。
到達不能だってlinterに怒られることもあります…
閉じ波括弧の後にelseに絶対続かない、catchにも続かない、他の制御や宣言に続かない。ということが絵的に分かりやすくて好んで付けてます。

>>159687
キャッシュを使うかどうかの判定はマスタープレイリスト(16進数16桁.m3u8)を読んだ時に起きるので、
repeat時にマスタープレイリストの読み直しが発生することがあるんですかね。

コードを"nvapi", "/v1/"でgrepした限りでは該当なし。
"/api/"は該当はあるけど関係ありそうなものはなさそう。

dms(domand)用に追加したコードは、watchページのdata-api-dataのjsonの把握と*.domand.nicovideo.jp通信のハンドリングがメインなので、これだけで取れるページと取れないページがあるのかも知れませんね。

>>159689
それで言われて分かった。
onRequestに同じような(微妙に違う)通信が複数回来るんです。
それで既にコンプリート処理が走った後にChunkListenerを通るcmfv,cmfa通信があるってことですね。
コンプリート処理が走ると一時フォルダがnullになるから、ということ。

この「onRequestに同じような通信が複数回来る」問題。
私が開発し始める前からあったので、もっと低レイヤーな通信部分に原因がありそうなんですよね…
ちょっと前にtlsからhttpを取り出すところを確認したら、その時点でほぼ同じ通信が2回通っていたので見当が付かないです。
curlで要求をするとonRequestを通るのは1回だけだったで、ブラウザとNicoCacheとの間に何かあるとは予想してますが。

<0034
<2024/03/20(水) 17:50:13.09
<開発途中版5，6試した。画質固定(720や360)だとブラウザ上で再生されない。
<-- video iv: ok
<-- audio iv: ok
<を繰り返してる。
ivの取得はサブプレイリスト取得時に起きるので、ニコニコ動画のプレイヤーが失敗を検知して、プレイリストの取得からやり直しているのだと思います。
サブプレイリストにkeyのURLが書かれていて、それを元にブラウザがkey urlへ要求を出し、正常な応答をするとNicoCacheはkeyを取れます。
繰り返していてkey:okが来ないということはkeyの取得が失敗している可能性が高いです。
keyのURLを取れないのかkey要求が失敗しているのかはブラウザの開発者ツール画面を見ないと分からないです。

キーURLが来た時点でそれを表示するようなメッセージを仕込みます。

<画質自動にすると「キャッシュしません」となるけど
<-- video key: ok
<-- audio key: ok
<になって再生できる。
画質自動だと失敗して、画質指定だと成功するというのだったら、まだ想定しているんだけど逆か…

画質固定の時にkeyが取れてないうえにNicoCacheがkeyの取得を妨害してしまっている可能性がある。
(※ivもkeyも復号情報です)
見当が付かない。
keyの取得妨害は一つ直したつもりだったけど、違う原因があるのか。

今の実装は、urlを見て、これはkey urlで、これはaudio用(video用)でという判定をしているので、サブプレイリストに書いてあるkey urlが未知の形式であるのかも。
これが原因なら、サブプレイリスト(オーディオビデオm3u8)をもっと正確に解析すれば回避出来る。
けど、どうしてこっちではそれが起きないのかが分からない。
やっぱりABテストなのかな。

>- urlが 〜/watch/数字の羅列 である動画に対応.
>
>- so動画にあった特殊な応答に対応.
>
>- 扱えるurlを拡張.
反応しないso動画問題は上記2つで解決しました。

>- key urlに関するdebug出力がブラウザ側のページに出ます.
未知のkey形式が要求されているかも知れないので、それをユーザーから私に報告させるための出力です。
watchページの一番下に出るので全く再生されないっていうタイプの人は見てみてください。
https://delivery.domand.nicovideo.jp/hlsbid/1234567890abcdef12345678/keys/audio-aac-192kbps.key?長い文字列
https://delivery.domand.nicovideo.jp/hlsbid/1234567890abcdef12345678/keys/video-h264-720p.key?長い文字列
こういう形式じゃない場合はNicoCacheが非対応している可能性があります。
(そもそも非対応形式は検出するはずだが)

鍵を取得し始めたときにログに以下のような表示も出ます。
​-​- video key: start
​
-​- video key: okも出たら成功です。

>- サブプレイリストの加工速度が遅い可能性がある.
>
>- keyの取得中に黙ってエラーしている可能性がある.


<0035
<2024/03/20(水) 21:16:19.68ID:gmJyp7Lf0
<開発途中版6（231111mod）　Firefox124
<ログに
<<304 not modified> was responded: video/01.cmfv
<<304 not modified> was responded: audio/01.cmfa
<が出るけど、sm も so もイケてる感じ。
304はもう出力しなくてもいいかも。

<長い動画だと再生ボタンを押して再生開始までに数秒ラグが出る。
コードの中の正規表現か処理そのもののどっちかが原因の可能性があります。

<生放送はやっぱり proxy.pac から *.dmc.nico を抜かないと
<ぐるぐるする。
nlFiltersに何かないかな。
そのドメインはもうキャッシュ出来るようなものを配信していないのでデフォで抜いちゃってもいいと思ってます。
まだちゃんと確認してないけど。

<-- video iv: ok
<で止まる so がある。
<so43521554 は止まる
<so43525958 は止まらない
コーディングミスの雰囲気あり。
so関係は今回の開発途中版7で機能を増やしたのでそれで解決するかも知れません。
ただ単に、プレイリストの加工にものすごく時間がかかっているだけの可能性もあります。

<so43525958 も途中で止まった。
<video/115.cmfv: 未完 15771/1844496
これは通信中断メッセージで「video/115.cmfv: 再開 数字-数字」みたいなメッセージも出るなら問題ないです。
「不明なpartial contentです」エラーも出ませんでしたか。

完全にキャッシュしないとキャッシュを利用した再生は出来ませんが、キャッシュの保存は部分的にやっていけるので、
もう1度動画を開いて、同じ画質で、115だから(115-1)×6÷60→11分24秒あたりから再生すると取れるはずです。

開発途中版7にて
<-- video iv: ok
<-- audio iv: ok
をうちも繰り返す動画があります。

720p→自動でキャッシュ出来た動画もあるけど、出来ない動画もある状況。

ブラウザ上のkey形式のdebug出力はなし。(キャッシュできる動画は表示される)
-- video key: startの出力もなく、
-- video iv: ok
-- audio iv: ok
+
-- video iv: ok
と出力が続き、CPU使用率が上がり続けます。

>>159693
とりあえず、コメントのtypoなので実害はないと思いますが、CmafCachingProcessor.javaの117の
shlbid
は
shlsbid
じゃないかと思います。

>>159694
再生出来ない状態のページの一番下にurlは出ていましたか。
出ていたら適当に部分部分を伏せ字にしてここに貼ってください(?以降を全部消してもいいです)。

この問題が解決したら一般向けに出来そうなんだけどな。

良ければどの動画か教えてください。
他の人も動作不良の動画があったら教えてください。

そのまま貼るのが恥ずかしければRSA暗号化ツール作ったので、
これで動画IDを暗号化してから貼ってください。
https://output.jsbin.com/yaperevebi
復号は秘密鍵を持っている#//FjlVだけが出来ます。
暗号文が350文字ぐらいになって格好悪いですが、まあ気にしない。

>>159696
ありがとう直しました。

>- サブプレイリストの加工速度をわずかに改善.
>
>- keyに関するログをさらに.
> プレイリストにkey urlを発見した時点でその形式を検証.
> ウォッチページの一番下への出力も継続.

アップロードコメントに書いたここのURLがhttpsじゃなくてhttpになってるや

>>159697
watchページの下部にURLは出ていません。

再生できない動画をいくつか貼ります。
http://www.nicovideo.jp/watch/sm43553860 [Embed]
http://www.nicovideo.jp/watch/sm43542014 [Embed]
http://www.nicovideo.jp/watch/sm43526993 [Embed]

再生できない動画を見てたら傾向が見えました。
・720p固定で再生できるのは12分弱の動画まで
・解像度自動で再生できるのは17分弱の動画まで
・20分以上の動画で再生できるものは(いまのところ)ない

再生時間、フレーム数、ファイルサイズあたりかな、と。
的外れだったらごめんなさい。

再生できない動画ではないのですが、ログにエラー？警告？っぽいものが出力されていた動画です。

http://www.nicovideo.jp/watch/sm2919788 [Embed]
http://www.nicovideo.jp/watch/sm3123256 [Embed]

・出力されたもの
未知のセグメント拡張子です: '' in [master.m3u8, 1/ts/playlist.m3u8]

>>159699
Q1. ブラウザは何を使ってますか。

こちらの環境では動画3つとも問題なく動作しました。
Q2. 安定して問題が起きるんですよね？（起きたり起きなかったりするわけではなく）

>・720p固定で再生できるのは12分弱の動画まで
>・解像度自動で再生できるのは17分弱の動画まで
>・20分以上の動画で再生できるものは(いまのところ)ない
>
>再生時間、フレーム数、ファイルサイズあたりかな、と。
ありえる。
今ニコニコ動画が使っている動画の中身は3階層になってまして、代表のマスタープレイリスト、そこに書かれている映像用プレイリストURLと音声用プレイリストURL、それぞれの中に書かれている映像断片のリストと音声断片のリスト。
一つの断片で6秒ぐらいです

挙動がおかしい時にiv: okが繰り返されるということは、映像用プレイリストと音声用プレイリストが繰り返し再要求されているということ。
それで、再生時間が長くなるほど、当然に映像用音声用プレイリストが長くなるんです。
長い時に未知の表現や非対応の表現が現れて来る可能性があります。

どうしようかな…
怪しいのが映像用音声用プレイリストだから、その内容をファイルに保存すれば、アップしてもらってこっちで解析が出来るか。

>>159700
再現しました。
空行を無視する処理を忘れてました。

これは壊れた加工プレイリストを作ってしまい再生不能の原因になりうる。
>RFC 8216 HTTP Live Streaming
>Blank lines are ignored.

ところでそれらの動画はdmc/hlsで配信されてるね。新仕様のdms(domand)ではなく。
全部切り替わったわけじゃなかったか。

キャッシュに失敗する動画です。
ページを更新してもエラーは解消しません。
ブラウザは FireFox です。

http://www.nicovideo.jp/watch/nm12478765 [Embed]

・エラー内容
サブプレイリストを検出出来ないためキャッシュしません: nm12478765

CMAF付与情報取得失敗: キー(NG), 値:(NG), smid(nm12478765) (ページ更新で改善しない場合、おそらくインジェクションjavascriptかnlFilterの構成が失敗しています) https://delivery.domand.nicovideo.jp/hlsbid/65f3fc1f0bb63ebe02e90713/playlists/media/audio-aac-192kbps.m3u8

>>159701
Q1
GoogleChromeを使用しています。
edgeも試しましたがNGでした。

Q2
再生できる、出来ないは安定して再現します。

>>159702
"-mid"っていう非対応のsuffixが付いていたせいでした。

キャッシュファイルの仕様がまた複雑になる。

昨日あげてた途中版9 id.192

>- プレイリストの空行の扱いが間違っていたのを修正.
> これは再生不能を引き起こしていた.
再生不可の原因がこれだけなら簡単なのだけど。
このバグを仕込んでしまったのは、たぶん開発途中版8でのことだから解決しない。

再生不可が起きる人でなおかつ詳しい人は、m3u8ファイルの応答ボディを見てみてください。
(ファイル名部分がvideoで始まるものを見てください。)
NicoCacheがそこに不正な行を生成してしまっていると予想しています。

開発途中版8
key urlの検証を追加しました。
>-- video key url: 形式ok
>-- video iv: ok
>-- audio key url: 形式ok
>-- audio iv: ok
非対応のkey url形式の場合にはそれが表示されます。
文字"?"以降を削ってスレに貼ってください。

>0039
>2024/03/21(木) 23:19:26.65
>プレミアム限定動画ですが
>(hls)暗号化ストリーミング動画のためキャッシュしません: so42851420
>再生開始まで
>(cmaf)no cache found: so42851420[1080p,192]_シャングリラ・フロンティア 2「特異なる者」.hls
>-- video iv: ok
>-- audio iv: ok
>が8回ほど出てきました。それまで動画再生はできませんでした。
再生失敗を続けていると前の動画配信仕様を使うようになるんだね。
so動画でも再生不能起きてるのか。

>0038
>2024/03/22(金) 01:10:22.37
>8試しました。再生出来る様になりました。
開発途中版8で直ったとすれば、プレイリスト加工のバグが原因だった可能性が高いです。

>0044
>2024/03/22(金) 20:38:21.16
>大量キャッシュさせると、途中で止まる確率高いかな。
>5個ぐらいが限度って所で、それ以上は、再生が開始されないとか、途中で止まってたりするので、
これはNicoCacheの問題かな？
元々ニコ動にリクエストを大量に送るとForbiddenとだけ書いてある応答が返ってくる確率が上がるので。

>0047
>2024/03/23(土) 00:54:38.81
>中身が複雑になってるから、mp42hlsはちょっと難航しそうな予感。
>前の1/ts形式だと、多分読めないよなぁ・・・。
>って、それ読めないと、キャッシュ全滅っぽ？
いえ。
dms(domand)動画に対応するついでに、動画キャッシュフォルダにmaster.m3u8があれば自由な形式を配信出来るような機能を追加したので、ニコニコ動画側のプレイヤーさえ対応していれば、任意のフォルダ構造で再生出来ます。
この機能が動作したというレスは見ていないけれども私の環境では期待通りに動いています。

dms(domand)で配信されるページでも、dmc時代のhlsキャッシュが使えています。

それとffmpegを使って単一ファイル動画(mp4とかflvとかwebm)をcmafにする方法。
>ffmpeg -i 入力動画 -c:v copy -c:a copy -f hls -hls_time 6 -movflags cmaf -hls_segment_type fmp4 -hls_playlist_type vod -hls_segment_filename "%d.m4s" 'master.m3u8'
>この方法で作ったmaster.m3u8をニコニコ動画のプレイヤーは再生出来る。(webmを入力とする場合も再生出来る)
>昔のmp4キャッシュやflvキャッシュが使える可能性が出来ました。
ts形式でもいいんだけど、これはvp8とかvp9のコンテナになれないからfmp4にしてます。

この機能は当然に、mp4キャッシュを変換して利用するための下準備です。
(セグメントへの分割処理は軽いからffmpeg.wasmとか使っても実現出来そうだし、そうすれ同梱配布が出来てインストール楽かもとか。まだ予定の段階です。)

>>159694
>>159699

ここで報告してた再生できない動画ですが、開発途中版9で再生可能なことを確認しました。

>>159709
再生不可が改善したという報告これで2つ。
よさげ。

- 開発途中版7までのm3u8に関する正規表現が間違っていた可能性が高い。
- 開発途中版8で1行ずつ処理するようにして、シンプルな正規表現に改善して
- 開発途中版9で空行の扱いを修正した

改善しなければ情報インジェクション手法をやめて、NicoCacheの内部でURLとどの動画に関するものかという連想配列を持つ設計に変えようと思ってた。
そっちの方がニコ動側の挙動を変えないから望ましいんだけどね。

>>159707
動画キャッシュ完了後の提供で、場面が指定されているとerrorが出るようです。エラーログが出ているだけで、表示には影響は出てなさそうです。
とりあえず、ログはこんな感じ

cache completed: sm43555540[1080p,192]_【琴葉茜】徒歩キャンプ実況 #9【冬キャン納】.hls
error: chunkavDir==null: 070.cmfv
error: chunkavDir==null: 071.cmfv
+
error: chunkavDir==null: 072.cmfv
error: chunkavDir==null: 073.cmfv
+
error: chunkavDir==null: 074.cmfv
error: chunkavDir==null: 075.cmfv

>>159711
これは一時ファイルを置くためのディレクトリが存在しないというエラーで、
キャッシュコンプリートしているなら問題にする必要ないので、
キャッシュコンプリート時はこのメッセージを出さないようにします。

今の実装だとコンプリートしたキャッシュフォルダに一時ファイルが残る可能性があるな…

id.192

途中版9とほぼ同じ
メインの変更点はutf8化だから挙動は変わらないはず。

>- そろそろ安定版宣言が出来そう.
>
>- 他に開発が続いているNicoCacheは見つからないため、起動時に表示されるバージョン
> をシンプルにします. ChangeLogでは長いバージョンの表記を使います.
> 変更前の最終バージョン.
> "NicoCache_nl+150304mod+231111mod (eR) (based on NicoCache v0.45)"
> 変更後.
> "NicoCache_nl version 2024-03-24"
> まるで来歴を省略してしまうようですが、必要と判断しました. 先人達に感謝を.
> 安定版ごとに日付を更新していくつもり.
>
>- ソースコードやtxtファイルなど全て、Shift-JISだったのをUTF-8へ変換.
> 半角カナなどは維持.
>
>- "360p-mid"や"360p-low"に部分的に対応しました. (部分的というのは"low"と"lowest"
> の順序比較を実装していないという意味.)

書き忘れたけどchunkavDir==nullを無視して良い状況では出力しないようにしました。

>0060
>2024/03/24(日) 11:24:49.87
>10について、
>srcの更新と、autobuild。
>nicocache_nlフォルダ直下のファイル群を更新しNicoCache_nl.jarを起動させると
>それまでできていたキャッシュがログから表示されなくなり動画のフォルダも作成されなくなりました
Q1. 配布のNicoCache_nl.jarを直接使った場合はどうですか(例えば起動時バージョンはどう表示されますか)
Q2. ant cleanやsrc下のclassファイルを削除、NicoCache_nl.jarの削除をした後にant jarするとどうですか

配布したNicoCache_nl.jarを使って最低限の構成で起動してみたけど期待通りに動作しています。
配布したファイルをcleanした上でant jarしてみたけれど期待通りに動作しています。
(そもそもコンパイル済みオブジェクトにあたるclassファイルはsrc下には同梱してないのだけれど)

autobuildってAutoBuild.batですよね？
>cmd /k "color 2E && TITLE AutoBuilder && cd %~dp0 && cd /d %~dp0 && ant extract jar"
使ってないから分からないけど問題なさそうなコマンドに見える。


上に書いた[誤:id.192]じゃなくて[正:id.194]だ。
ところでアップローダーの[id.194 開発途中版10]が3/4ぐらいまでダウンロードしたあたりで失敗する。
再試行しても失敗する。
代わりのファイルを上げておきます。

関係ないけど起動時にjavaのバージョンチェックコードを追加した方がいいな。
java 19では動かない。
java 18では検証してない。
java 11では動く。

id.195 10-2もダウンロード不可

アップロード時に1回エラー後にアップ成功

https://nicocache.jpn.org/
サーバーエラー
jqXHR: {"readyState":0,"responseText":"","status":0,"statusText":"error"}
textSattus: error
errorThrown:

>>159715
18だと
"failed to set workaround for allowing patch method: java.lang.Class.getDeclaredFields0"
で一部しか動かないっぽいですね。
getDeclaredFieldsのDirtyHackがとうとう塞がれてるみたい。
https://stackoverflow.com/questions/56039341/get-declared-fields-of-java-lang-reflect-fields-in-jdk12

19だとThreadの動作変更で
DirectoryWatcherが動かないんじゃないですかね。

>>159715
18だと
"failed to set workaround for allowing patch method:java.lang.Class.getDeclaredFields0"
でロードは出来るけど正しく動作しないかな。
https://stackoverflow.com/questions/56039341/get-declared-fields-of-java-lang-reflect-fields-in-jdk12
DirtyHackが塞がれたからっぽい。

19は
DirectoryWatcherが上手くいかないのかな。
Threadの動作変更の影響だと思う。

ダブった上に18のは勘違いでした。
17でも
java.lang.NoSuchMethodException:java.lang.Class.getDeclaredFields0
出るけどキャッシュまわりは動きますね。

>0062
>2024/03/24(日) 13:35:55.49
>起動時バージョンはNicoCache_nl version 2024-03-24
>195で配布されているjarを直接現在使っているファイルに移動、差し替えをしてもキャッシュはできませんでした。
>ant clean 、ant jar、作業後の　NicoCache_nl.jar　もキャッシュはできませんでした
バージョンは期待通りで正しい。
エラーも何も出ていないというのが分からない。

Q. [2024-03-24 23:22:04.868] Filters Loading Time: 35ms
みたいな表示の後に何かでますか。

Q. その状態で動画の再生はされますか。

Q. 確実にキャッシュされていない動画を再生した時に、動画ページの一番下にURLは出ていませんか。
(あるかないかだけ答えてくれればいいです。
　開発途中版10にはkey urlをデバッグ出力するコードを残しているので、それが動作しているかどうかを質問しています)

Q. 開発途中版10よりも前の、使ったことのある途中版番号覚えていますか。

Q. https://delivery.domand.nicovideo.jp/local/url_injection_sys.js
ここにアクセスして何か表示されますか
（スクリプトっぽい内容なら異常ナシ。Missing Keyと表示されたらconfigかproxy.pacがおかしい）

Q. コマンドプロンプトで動かしていますか。あるいはNicoCacheGUIを使っていますか。
（後者は私は使ったことがない上に動作させれないので分からないのだけれど、エラー出力が別タブになっていたような）

>Running with Java 14.0.1(amd64) on Windows 10
こちらではjava11と17でテストしてます。
14は手に入れるのにひと手間あるから試してないけど、環境が原因ならエラー出力があると思うんだよね。

>>159718
Workaroundコードは、jdk/jreのバージョンが上がれば必要がなくなるはずだからそこは純粋に消しちゃえばいいはず。
今はおっかなびっくりだから残してあるけど。

移行するとしたら、まずはjava17に一本化して、workaroundを削って、それから次のLTS版javaにという感じかな。
java17以外を使っていると、起動時にメッセージと共にN秒待たせてユーザーの環境移行を促すとか。

DirectoryWatcherは必須ではないからちょっと不便状態でちょっとずつ移行していくのも手段候補。
それはともかくThreadは影響範囲が広くて何かあったら検証が難航しそうだな…

>>159719
こちらのopenjdk-17-jdk 17.0.9だとそのエラーは出ないです。

5chのスレ 60,62,63,65,66とは別人ですが、同じ動画がキャッシュできるか試してみました
ログに「CMAF付与情報取得失敗」と出ていますが、動画のキャッシュはできています
キャッシュ完了後、「キャッシュ削除」ボタンからキャッシュを削除した後
ページを更新して再度キャッシュする場合はログに「CMAF付与情報取得失敗」は出力されませんでした

・環境
(ブラウザ)
FireFox 124.0.1

(Java)
openjdk 17.0.8.1 2023-08-24
OpenJDK Runtime Environment Temurin-17.0.8.1+1 (build 17.0.8.1+1)
OpenJDK 64-Bit Server VM Temurin-17.0.8.1+1 (build 17.0.8.1+1, mixed mode, sharing)

(NicoCache)
NicoCache_nl 開発途中版10-2
動画ページの一番下にURLは出ている(key urlのデバッグ出力)

・ログ1
(cmaf)no cache found: so43543401low[720p,192]_(削除).hls
+
-- audio key url: 形式ok
-- audio iv: ok
-- video key url: 形式ok
-- video iv: ok
-- audio key url: 形式ok
-- audio iv: ok
-- video key url: 形式ok
-- video iv: ok
-- video key url: 形式ok
-- video iv: ok
caching so43543401
+
-- video key: ok
-- audio key: ok
-- first segment ok: audio/001.cmfa
caching so43543401
video/001.cmfv: 未完 1572250/2122480
video/001.cmfv: 再開 1555866-2122480
-- first segment ok: video/001.cmfv
caching so43543401
++++++++
CMAF付与情報取得失敗: キー(NG), 値:(NG), smid(nullnull) (ページ更新で改善しない場合、おそらくインジェクションjavascriptかnlFilterの構成が失敗しています) https://delivery.domand.nicovideo.jp/hlsbid/65f8f5e0c1a36e06f2ce74b9/keys/video-h264-720p.key
caching so43543401
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
cache completed: so43543401low[720p,192]_(削除).hls

・ログ2
Remove All Cache: so43543401
(cmaf)no cache found: so43543401low[720p,192]_(削除).hls
+
-- audio key url: 形式ok
-- audio iv: ok
-- video key url: 形式ok
-- video iv: ok
-- video key url: 形式ok
-- video iv: ok
-- audio key url: 形式ok
-- audio iv: ok
-- video key url: 形式ok
-- video iv: ok
caching so43543401
+
-- audio key: ok
-- first segment ok: audio/001.cmfa
-- video key: ok
caching so43543401
video/001.cmfv: 未完 982426/2122480
video/001.cmfv: 再開 966042-2122480
-- first segment ok: video/001.cmfv
caching so43543401
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
cache completed: so43543401low[720p,192]_(削除).hls

<0066
<2024/03/25(月) 06:42:26.96
<動画再生のページにはURLはありません
<MissingKeyMissing Key-Pair-Id query parameter or cookie value　とでます
NicoCacheを通らずに通信してる。

可能性2つ。mitmHostPortの設定ミスとプロキシ設定のミス。

config.propertiesにmitmHostPortを設定する項目があったら消してください。
config.properties.defaultにコメント行以外が書き込まれている場合はconfig.properties.defaultファイル自体を削除してください。

defaults/30_NicoCache_nl_TLS.propertiesに
mitmHostPort=*.nicovideo.jp *.ce.nicovideo.jp *.sl.nicovideo.jp *.domand.nicovideo.jp:* *.sv.nicovideo.jp *.nicoad.nicovideo.jp *.seiga.nicovideo.jp *.smilevideo.jp *.nimg.jp *.cdn.nimg.jp *.dmc.nico:*
の行があることを確認してください。
特に"*.domand.nicovideo.jp:*"が無い場合はそれが原因です。
アーカイブの上書きが失敗しています。(でもこれは開発途中版1で既に変更しているから可能性低い)

もう一つがproxy.pacやプロキシ設定のミス。
proxy_sample.pacを使っていれば通信出来るはずです。

ブラウザや環境に設定しているpacファイルが実在するか確認してください。
その内容を確認してください。
よく分からなければ、proxy_sample.pacをそのまま使ってみてください。

https://www.nicovideo.jp/local/url_injection_sys.js
https://delivery.domand.nicovideo.jp/local/url_injection_sys.js
これらにアクセスして両方にスクリプトっぽい内容で、NicoCache_nlという文字列が含まれている必要があります。
文字化けしててもそれは問題ではないです。

>>159722
>CMAF付与情報取得失敗: キー(NG), 値:(NG), smid(nullnull) (ページ更新で改善しない場合、おそらくインジェクションjavascriptかnlFilterの構成が失敗しています)
他に動画ページを開いたままNicoCacheを再起動したりしました？
このエラーが出た後もターゲットの動画は取れてるから多分別のページのものなんだろうけど。

意図的に読み込みエラーを大量に出すとインジェクション失敗が起きることがあるからRequest Object経路を通るパターンが存在するのかな。

>>159724
同じブラウザの別タブで別の動画の再生中に出ました。
再生していた別の動画はキャッシュ済みの物です。
NicoCache_nlの再起動はしていません。

<0069
<2024/03/25(月) 19:58:10.98
<過去のNicoCache_nlを新しいフォルダに、3-24のNicoCache_nlを過去のフォルダとで交換し適度させたところ、
<3-24の起動時、されたURL２つに文字化けの中にNicoCache_nlという文字列が含まれた画面が出てきました
じゃあもう動画キャッシュ動作してるんじゃ？

<mitmHostPortが短かったのでペーストして上書き長くしました。
短かったということは defaults/30_NicoCache_nl_TLS.properties が上書きアップデートがされてない。あるいは古いそのファイルが混入している。
書き込み禁止属性が設定されているから上書き時ダイアログで「上書きしない」を選びませんでしたか。

一度7zファイルの中からdefaultsフォルダをコピーして上書きした方がいいです。

他にも不整合が起きていそうで気になるけれど、動いているならそれでいいです。

pacファイルを元々使っていたものに戻してみて、それでキャッシュ動作するなら原因はmitmHostPortの設定だったということです。

<default部分を削除してconfig.propertiesとして機能させています
<まずかったでしょうか
アップデート時に配布されるファイルで上書きされることを回避出来ればいいのでそれでいいです。

>>159725
挙動気になる。致命的エラーにはならないけど。

虚しいところから今北産業

リリース
id.196 2024-03-26
>NicoCache_nl+150304mod+231111mod+240326mod
>
>・dms(domand)，2023年11月からの動画配信仕様に対応
>・プロキシ対象のサブドメイン，*.domand.nicovideo.jpが増えました．documents/Readme_TLS.txt の手順をもう一度行なってください(開発途中版を試していた方はそのcertsのコピーでいいです)．pacファイルは変更なしです．
>・キャッシュ拡張子はdmc時代と同じくhls
>・個別キャッシュフォルダにmaster.m3u8さえあれば，任意のフォルダ構造をキャッシュとして配信する機能を追加
>・文字コード変更．ソースコードやtxtファイルなど全て，Shift-JISだったのをUTF-8へ変換．半角カナなどは維持
>・他に開発が続いているNicoCacheは見つからないため，起動時に表示されるバージョンをシンプルにします. ChangeLogでは長いバージョンの表記を使います．
>・231111modのワークアラウンドを削除
>・showCachingオプションを追加．断片キャッシュを受信する度にログします．しばらくはデフォルトtrue．不要な方はconfig.propertiesにshowCaching=falseを追記してください

重大そうな不具合報告が無いので安定版宣言します。

中身は開発途中版10とほぼ同じだからそれで十分な人はアップデートしなくていいです。
同梱ドキュメントが若干整理されています。

TODO:
- javaバージョンの引き上げ
| - まずはjava 17に一本化. java 17以外で起動遅延などで促し
- 不必要なWorkaroundの削除
- インストールとアップデートの簡単化
| - config_env.txt(環境設定スクリプト)の導入
| - 理想的にはconfig.propertiesを移動するだけでアップデート出来るといい
| - ユーザー用nlFiltersディレクトリ，ユーザー用localディレクトリなどを設定出来るように．
| これがあればNicoCacheフォルダの外にユーザー用それらファイルを配置出来る．アップデート時の上書きを気にしなくてよくなる
- キャッシュ済リンクの色付けをstyle直書きではなくクラスへ
- キャッシュファイルリストの動的再読み込み

<0075
<2024/03/27(水) 19:46:59.85ID:ZJngD/12d
<安定版とのことだが…
<https://www.nicovideo.jp/cache/（適当な動画ID）/auto/movie
<で動画が再生されないバグは直してもらえたのだろうか？（不安）
そのあたりは全然触ってない。
これってそもそもファイル実体を返す機能（たぶん）だから、
hls動画はプレイヤーをどっかから見繕って来ないと再生出来ないです。
mp4はブラウザが再生に対応しているからそのまま再生出来るけれど。

まあhls.jsかな。

<0076
<2024/03/27(水) 23:56:17.48
<【再生されない】ことは問題でなくて、このリンクでそもそもファイル実体が返ってこない（＝404 Not Found）ので直して欲しいという意味でした。
そこまでは把握してます。
問題としては難しくないのだけれども、hlsは複数のファイルからなる動画だから、404を直しても無味乾燥な代表プレイリストファイル(master.m3u8)のテキストが返ってくるだけになってしまいます。
ディレクトリ型動画の存在を想定した仕様ではないため、仕様を一意に決めることが出来ないです。

というかこのAPIの目的って一体なんなのだ。
ダウンロードが目的であるならffmpegでmp4に変換してそのmp4を返すという挙動、あるいはhlsフォルダをzipでまとめて返すという挙動が重いが綺麗。
あるいはhls動画の場合は、404じゃなくて「405 Method Not Allowed」を返すというのも綺麗。

ブラウザでキャッシュ動画を再生する目的なのであれば、先の答えの通りhls.jsを使った再生ページを作るということになります(そのための基盤はdms/domandのために組んだし)。

>./local/CustomFilters/UserPage/up.js
>動画を新規ウィンドウに開いてローカル保存

>NicoCache_nl+150304mod+170106mod (Patch Release, 人柱版)
>・WebAPI /cache/<smid>/{movie,audio} の挙動を変更しました．
>　これまで<smid>にlowがついていない場合は，(非dmcの)通常キャッシュとエコノミー
>　キャッシュから自動で選択して結果を返していましたが，非dmcの通常キャッシュから
>　結果を返すようになりました．
>　dmcキャッシュを含めたキャッシュから自動で選択して結果を返す新しいWebAPIは
>　/cache/<smid>/auto/{movie,auto} です．

/cache/下のURL仕様は把握していないけれど、たぶん相対的参照によってファイルリソースを返すような機能がない(master.m3u8からvideo.m3u8を参照出来ないし、そこからさらに動画セグメントを参照出来ない)。
そうなると既存のURL仕様ではhlsに対応出来ないです。

<>ディレクトリ型動画の存在を想定した仕様ではないため、仕様を一意に決めることが出来ないです。
<すみません、ここどういう意味なのか分かりかねます。
旧仕様は動画が一つのバイナリーコンテンツで表せることを前提としている(flv,mp4,swfとか)。
複数のファイルからなる動画キャッシュ(hlsキャッシュ)を求められた時の振る舞いを決められない。
複数のファイルをいっぺんに配信したりダウンロードさせたりする仕様がhttpには無いから、このWebAPIには担わせられない。
といった意味合いでした。
※前提知識。hls動画は1〜3つのm3u8ファイルと複数の動画部分ファイル(ts,cmfv,cmfaなど)からなります。

<・APIから得られた.m3u8をニコニコ動画プレイヤーに引き渡して再生させる（hlsになる前は実際にフィルタまとめで使用していました。）
m3u8ファイルだけ渡しても関連ファイルが読めないから、単純な実装だと無理だと思います。

># ローカルFLVサーバ機能 (true/false)
># flvplayer_wrapperのローカルFLVに必要な /cache/ フォルダの動作を行います
># /cache/<smid>.flv のアクセスに対してキャッシュを返すようになります
># trueで有効、falseで無効
>localFlv=true
とても古い。
フラッシュで実装されていた代替プレイヤーももう機能終了(end of life)しているから、仕様は好きに決めていいか。

m3u8を再生する場合は、その中に書かれているファイルにもアクセス出来るようなURL仕様になっている必要があります。
この要求がネックで旧仕様にはhls対応を追加出来ません。
キャッシュしているmaster.m3u8の中身だけ返してもいいけど、これが嬉しいシチュエーションは存在しないです。

例えば http://localhost/cache/sm9.hls がmaster.m3u8の中身を返し、それで動画を再生しようとした場合、中にかかれているパスに相対的にアクセスします。
だから例えば、自動的に次のようなURLへアクセスしようとします
http://localhost/cache/1/ts/playlist.m3u8
あるいは http://localhost/cache/video.m3u8

/cache/以下は既に絡まった仕様が存在するから、hlsをhlsのまま配信する仕様対応はしない。
<だからURLの選択肢で挙動が変わるのが理想的なのかも？
これの通り、mp4に変換して返すという処理を追加して、/cache/(smid)/auto/movie はそこへリダイレクトするというのが順当か。
ユーザーが求めるものこれだろうし。
ffmpegは必須。

<0078
<フィルタまとめのcommon.js146行～169行目では
<https://www.nicovideo.jp/local/CustomCache/（smid）.hls/master.m3u8
<もしくは
<（smid）.mp4
<を返すようにしてニコニコ動画プレイヤーで上手く再生されてるけど何か違うのかな？
知らない仕様だ…
添付画像の部分のことだと思うけど、この部分って404判定されるのでは？
それにこのコードってhls動画は再生出来ないような。

順に書いてて気付いたが
>（hlsになる前は実際にフィルタまとめで使用していました。）
これってそれの話か。

よく分からないからとりあえず考えているものを実装します。

id.197
>開発版12 2024-03-29:
>- WebAPIを更新．/cache/<smid>/auto/movie アクセス時に，smidがhlsキャッシュ動画であった場合は，下記のmp4 URLへリダイレクトし，mp4が得られます．
>- /cache/sm9.mp4
> /cache/sm9.hls.mp4
> /cache/sm9[360p,128].mp4
> などにアクセスした場合に、キャッシュがhlsであっても、mp4に変換して返します.
>- ffmpegがインストールされていない場合は失敗します．
>- 開発版11は欠番です.

>- 2024-03-29: hls→mp4仕様を追加. あまり検証していないが従来の仕様とは衝突しないはず. これを実装前はhlsキャッシュに対する要求には404を返していた.
>- /cache/<smid>/auto/movie アクセス時にhlsキャッシュ動画であった場合は、下記のようなmp4 URLへリダイレクト.
>- https://localhost/cache/sm9.mp4
> https://localhost/cache/sm9.hls.mp4
> https://localhost/cache/sm9[360p,128].mp4
> などにアクセスした場合に、キャッシュがhlsであっても、mp4に変換して返す.
>- webm,mkv,flvへの変換にも対応しているがまだ使い途はない. 動画コンテナがコーデックを扱えない場合は失敗する.

とりあえず。

< 0080
< 2024/03/29(金) 00:28:36.35
< 違います。私が話しているのはこの行です。（しっかり行数指定したはずなのだが…）
< https://i.imgur.com/S1FV6ho.png
たぶんこっちが持っているcommon.jsが古いです。
m3u8への言及がそもそもこちらのソースコード内にない。
あとで更新します。

< この画面は/local/CustomCache/so41635862.hlsを再生しているときのものです。
この仕様も知らなかった。

でも話が見えました。
今回のアップデートは回避策として機能すると思います。

< https://www.nicovideo.jp/cache/(smid)/auto/movie
< がmaster.m3u8を返せば良いという問題でもなくなるのか。
< という風に読み込もうとするから/local/フォルダでは上手く機能しても
< https://www.nicovideo.jp/cache/(smid)/auto/movie
< では上手く機能しないのか。やっとわかった。
はい。

hlsキャッシュフォルダのファイルを配信するための機能はNicoCache本体に書いたので、そこへリダイレクトするという手もあります。
（この配信機能を使ってdms動画キャッシュは動いてます）
WebAPI/URL仕様を定めてNicoCache外部からの要求にも答えられるようにすれば、mp4にしなくてもhlsが使える。

まずはhls配信用の独自パス( /eachcache/key1=value1&key2=value2//master.m3u8 )を /cache/each/ とか /cache/smidfiles/ とかにする作業が先。
仕様の不統一感は残さない方が良い。

<0100
<2024/03/30(土) 23:53:02.67
<安定版12使ってるんだけど、4分程度のボカロ系の音源を70個ぐらい同時に開くと、キャッシュに失敗するね
<「ページを更新してください」ってログに沢山出てきてる
12は開発版です。というのはおいといて。
「ページを更新してください」エラーは大量リクエストだからと言って出るはずはないから、想定漏れ・設計ミスがやっぱりあるみたいです。
（大量リクエストによるエラーならただ単に再生が止まるか、プレイリストが不正だってエラーになるはず）

ニコ動は利用していないと思っていたRequestコンストラクタ経路もurl_injection_sys.jsの対応に入れてみます。

あるいはインジェクション用スクリプトがheadタグの一番最初に来ないのがいけないかな。
このスクリプトよりも先に挿入されるのはどれもNicoCache関連だから問題無いはずだが。

あ。
連想配列の上限(30個)にひっかかってるんだ。
内部の問題だ。
単に拡張すれば上手く動くようになるはず。
とりあえず300。

dmc時代も似たような処理をやってたから、同じような制限にひっかかってたはずだけど、何で上手くいっていたのだろう。

id.198
開発版13 2024-03-31:
- 内部的な同時キャッシュ上限を動画30個から200個へ
- /cache/ のキャッシュリスト処理が失敗していたのを修正．キャッシュファイルの最終サイズがnullを返す場合があり、それで例外エラーしていた
- 内部で使っていたURLの /eachcache/ を /cache/file/ へ移動
- javascriptのRequestオブジェクトにインジェクション用ラップを追加

>>159737
開発版13だと、ニコニコ動画の画面上部のメニューが表示されなくなります。開発版12に戻すと大丈夫でした。

Firefoxだと
> - javascriptのRequestオブジェクトにインジェクション用ラップを追加
の部分がエラーになって止まっているように見えます。

id.199
開発版14 2024-04-02:
- 開発版13で追加したjavascriptのRequestオブジェクトインジェクション用ラップを削除

今回の変更は url_injection_sys.js だけだから、添付ファイルの中身で local/url_injection_sys.js を差し替えることでも対応出来ます。

>>159738
ありがとうその通りみたいです。

<0125
<2024/04/02(火) 03:58:42.47
<開発版13を使っています
<ニコレポの取得に失敗します
<12の方では機能しておりました
これも同じ原因でした。

id.203

開発版16 2024-04-07:
- java21で動くように．
　- Workaround.javaの実装を変更(この実装もjava22以降では使えないのだとか)
　- 起動スクリプトNicoCache_nl.{bat,sh}を変更．java起動引数を追加．

開発版15 2024-04-XX:
- "Connection reset by peer"判定に関するWorkaroundを削除(回避すべきバグがjava11で再現しないため)．

変更の大部分は Workaround.java です。

>>159742
21.0.2で動きました。
あと>>159719
で出た17.0.10のエラー、JVMがOpenJ9 0.43だったからでした。

>>159743
検証素早い。
>あと>>159719
>で出た17.0.10のエラー、JVMがOpenJ9 0.43だったからでした。
実を言うと私java詳しくないのだけれど、openjdk付属のとは別のjava仮想マシンを使ったらエラーしたということ？

旧:
>Method getDeclaredFields0 =
> Class.class.getDeclaredMethod("getDeclaredFields0", boolean.class);

新:
>for (Method x : classMethods) {
> if ("getDeclaredFields0".equals(x.getName())) {
> declaredFieldMethod = x;
> };
>};

なんでここ違うのかなと思いながら写経してた。汎用性に違いがあるのかな。
もしかすると新実装(java21対応板NicoCache)だと例外出ないかも知れない。

>>159744
そうですね。Adpotium OpenJDKとかのHotspot VMではなくて
OpenJ9 VMが使われてるSemeru JDKで動かしてました。
https://eclipse.dev/openj9/
JDKのバージョンと一対一じゃないので、ドキュメント外の動作は最新版に沿いやすいんですよね。
でも殆どの場合Hotspot VMなので気にしなくて大丈夫です。

開発版16、Semeru 21.0.2（opneJ9 0.43）で動かすと
'failed to set workaround for allowing patch method: Cannot invoke "java.lang.reflect.Method.setAccessible(boolean)" because "<local2>" is null'
ってなりますけど本体の動作はします。Extensionはわからない。

>>159745
ダメか。しかも予想外なところがエラーしてる。
あとは手元で検証しないと分からない感じ(重要でないらしいし、なさそうだから今はやらない)。

2010年に追加された機能
># (実験的機能) HTTPヘッダに非ASCII文字を含めるブラウザでも
># 動作するように試みる。(true/false)
>useWorkaroundForEncoding=false

2022年に不具合修正された機能
># JavaのHttpURLConnectionがPATCHメソッドを受け付けるようにする
># JavaのHttpURLConnectionはPATCHメソッドのリクエストを送信させようとすると
># 許可されているメソッドの一覧に含まれていないとして例外を投げるため、
># リフレクションを利用してこの許可リストを書き換えることで回避する．
># PATCHメソッドはタイムシフト予約などで使用されている．
>useWorkaroundForAllowedMethods=true

この2つのためにリフレクションによる動的書き換えコードがあるだけだから、例外が出ても動きはします。
残りもう1つのdirty workaroundは終了時に接続切断を早めるためのものだし。

ニコニコのトップ画面を開くと毎回こんな感じのログが出ます。
以前はトップ画面で表示される動画はキャッシュしていなかった気がするのですが、勘違いですかね？

・ログ
CMAF付与情報取得失敗: (キー:ng, 値:ng, smid:nullnull) (ページ更新で改善しない場合、おそらくインジェクションjavascriptかnlFilterの構成が失敗しています) https://asset.domand.nicovideo.jp/661224c5b689b8443fc767b2/audio/1/audio-aac-192kbps/36.cmfa　(長いのでカット)

・環境
(ブラウザ)
FireFox 124.0.1

(Java)
openjdk 17.0.8.1 2023-08-24
OpenJDK Runtime Environment Temurin-17.0.8.1+1 (build 17.0.8.1+1)
OpenJDK 64-Bit Server VM Temurin-17.0.8.1+1 (build 17.0.8.1+1, mixed mode, sharing)

(NicoCache)
NicoCache_nl 開発版13
動画ページの一番下にURLは出ていない

(proxy.pac)
サンプルでついてきた proxy_sample.pac を proxy.pac にリネームして使用

>>159747
トップみたいなページの動画では、動画ID(sm123)が取得出来なくて必ずキャッシュ失敗するので、エラー表示が鬱陶しい以外には実害はないはずです。
でもエラー表示が過剰なので後でなんとかしておきます。

>以前はトップ画面で表示される動画はキャッシュしていなかった気がするのですが、勘違いですかね？
旧仕様がどうやって回避してたかは調べてないです。
dms(domand)仕様でもキャッシュしようという意図はないです。

実装上、動画形式のURLが来ると反応しちゃうのでそれでたくさんエラーが出てます。
黙ってキャッシュ失敗するよりもエラーが出たほうがいいかなってことでエラー出力を優先する実装にしてあります。

トップみたいにキャッシュしない目的のページには抑制を仕込んでおきます。

https://nicocache.jpn.org/download.php?id=205&key=631f904d23f05602d2545b87e65689f8d202289c27b4cb0f5cd670e5b9a49dd6

開発版17 2024-04-09:
- 動画ページ以外に配置されている動画で、NicoCache側に大量のエラーが出る問題を修正．

>>159747
修正しました。

解決してない。
ドメイン逃しがあった。

どうもweb worker環境にインジェクターを設置する必要がある。
ちょっと気合が必要そうだから、回避策としてそのエラー自体を出ないようにしようかな。

開発版18 2024-04-10:
- 動画ページ以外の動画で、NicoCache側に大量のエラーが出る問題を修正．

https://nicocache.jpn.org/download.php?id=206&key=631f904d23f05602d2545b87e65689f8d202289c27b4cb0f5cd670e5b9a49dd6

embed.nicovideo.jp/watch/以下にもurl_injection_sys.jsを設置。
url_injection_sys.jsとCmafCachingProcessor.javaにエラー抑制を追加。

2024-03-26(安定版1)を使っているんだけど、こいつが生成する.cmfaファイルって.cmafのtypo?
nlMediaInfo噛ませるとInvalid File Extension:braw mov qtって出るんだけど。

https://www.liveinstantly.com/ja/resources/cross-posts/cmaf-format/
>CMAFとは？
>Common Media Application Format (CMAF) は、様々な形式の HTTP ベースのメディアをパッケージ化して配信するためのフォーマット規格で、比較的新しい仕様です。 この規格は、HLS プロトコルと MPEG-DASH プロトコルの両方でデータを統一されたトランスポート コンテナー ファイルにパッケージ化することにより、再生デバイスへのメディアの配信を単純化します。

俺の勘違いかな。でも拡張子が違うって出るのはなんだろう。

>>159759
>>159760
typoではないです。
ニコニコ動画(というかAWS)が投げてくるファイルの拡張子がcmfv(動画)とcmfa(音声)なんです。

ffmpegも引数で抑制しないと一般的な拡張子じゃないというエラーを吐きます(.tsや.mp4は一般的な拡張子)。

nlMediaInfoの中身は確認していないけどそういうエラーだと思う。

でも
>Invalid File Extension:braw mov qt
".braw" , ".mov" , ".qt" はどれもdomand動画では使わないしNicoCacheはこれらを生成しないはず。

---

ところで開発近況です。
hlsキャッシュをユーザーが参照するためのAPI整備はちょっと難航してます。
品質別応答のための内部整理が難しいから、もう諦めて動画のsm idだけを見て、それで最良の品質を返す形式をまず実装する方針です。


開発版18も安定版にマークしたいけど、こういう場合どう運用するのがいいか決めないと。
毎回安定版のつもりでリリースすると確認作業が多くて開発版という装丁で出してるのだけど。

ニコニコのトップ画面を開くと毎回こんな感じのログが出ます。
設定が足りないのでしょうか。

・ログ
CORS configurations are loaded.
failed to set workaround for allowing patch method: Unable to make public java.lang.invoke.MemberName(java.lang.reflect.Field,boolean) accessible: module java.base does not "opens java.lang.invoke" to unnamed module @7c30a502

・環境
(ブラウザ)
125.0.2 (64 ビット)

(Java)
NicoCache_nl version 2024-04-10
Running with Java 17.0.11(amd64) on Windows 10

(NicoCache)
NicoCache_nl 開発版18
動画ページの一番下にURLは出ていない

(proxy.pac)
サンプルを proxy.pac にリネームして使用

>>159764
>CORS configurations are loaded.
エラーではないです。しかし、トップ画面を開く度に出るのはおかしいです。

>failed to set workaround for allowing patch method: Unable to make public java.lang.invoke.MemberName(java.lang.reflect.Field,boolean) accessible: module java.base does not "opens java.lang.invoke" to unnamed module @7c30a502
エラーです。その上で、トップ画面を開く度に出るのはおかしいです。

どちらもニコニコ動画のページがおかしくなるとか、動画が再生されないとかの症状がなければ無害です。

どちらのメッセージもNicoCacheを起動したあと1回だけ実行されるコードで出る・出る可能性があるのだけど、 https://www.nicovideo.jp/ を開くたびに出ますか？

すいません。トップ画面ではありませんでした。
nlの起動時のログにに出てくるものでした。
申し訳ありませんでした
1回しか出てきませんので、気にしないことにします

ありがとうございます

>>159766
ただ"failed to set workaround for allowing patch method"の方はjava 17では出ないはず(のつもりで組んだ)からちょっと気になります。
"Running with Java 17.0.10(amd64) on Linux"でテストしててこちらではエラーしない。
そちらとはマイクロバージョンが1しか違わないのに。

そのエラーっていつから出始めました？
開発版14(2024-04-02)以前では出てなかったのであれば開発版16(2024-04-07)での実装変更のせいかも。

>>159767
いつからかはわかりませんが、開発版途中から出てき始めたのは覚えています

起動時の「failed to set workaround ～」のメッセージですが
安定版1(NicoCache_nl version 2024-03-26)では出ないのですが
開発版16(NicoCache_nl version 2024-04-07)に変えるとでてきます。

(Java)
openjdk 17.0.8.1 2023-08-24
OpenJDK Runtime Environment Temurin-17.0.8.1+1 (build 17.0.8.1+1)
OpenJDK 64-Bit Server VM Temurin-17.0.8.1+1 (build 17.0.8.1+1, mixed mode, sharing)

>>159768
>>159769
旧実装だとエラーが出ないなら旧実装と新実装の両方を並べる方法取れば可用性が上がるかな。
格好悪いけど。

ところでこのエラー("failed to set workaround for allowing patch method")は、タイムシフト動画で利用される通信に対応するための回避策コードを完了出来なかったという意味です。
だけれど、いまプレミアム会員ではないので動作検証出来ていないです(回避策が完了出来た場合にPATCHメソッドが通ることは確認してるけど)。
そもそもこの回避策が今でも必要なのかどうかも不明です。