a random librejp banner

/librejp/ - librejp end

librejp@endchan


New Thread
X
Max 20 files0 B total
[New Thread]

Page: Prev [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] Next | [Index] [Catalog] [Banners] [Logs]


thumbnail of NicoCache.png
thumbnail of NicoCache.png
NicoCache png
(23.18 KB, 255x255)
■【ニコニコ】自動ローカル保存プロクシ NicoCache26 
https://egg.5ch.net/test/read.cgi/software/1710411967/

■NicoCache関連ファイル置き場 避難所3
https://nicocache.jpn.org/
48 replies omitted. Click to expand viewer
< 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//{movie,audio} の挙動を変更しました.
>  これまでにlowがついていない場合は,(非dmcの)通常キャッシュとエコノミー
>  キャッシュから自動で選択して結果を返していましたが,非dmcの通常キャッシュから
>  結果を返すようになりました.
>  dmcキャッシュを含めたキャッシュから自動で選択して結果を返す新しいWebAPIは
>  /cache//auto/{movie,auto} です.

/cache/下のURL仕様は把握していないけれど、たぶん相対的参照によってファイルリソースを返すような機能がない(master.m3u8からvideo.m3u8を参照出来ないし、そこからさらに動画セグメントを参照出来ない)。
そうなると既存のURL仕様ではhlsに対応出来ないです。
thumbnail of Screenshot.png
thumbnail of Screenshot.png
Screenshot png
(292.56 KB, 1339x1128)
<>ディレクトリ型動画の存在を想定した仕様ではないため、仕様を一意に決めることが出来ないです。 
< すみません、ここどういう意味なのか分かりかねます。
旧仕様は動画が一つのバイナリーコンテンツで表せることを前提としている(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/.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//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//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/ とかにする作業が先。
仕様の不統一感は残さない方が良い。

スマホの充電池が割れそうなんだがどうすんのこれ
燃えないゴミで引き取ってくれない
向こうに書いたけど無料回収やってる怪しい業者が回収してくれる
とはいえ捨て方が無いバッテリーを無制限に売ってる現状はどうかと思う
リポバッテリーなんか有償処分しかないんじゃないか

 >>/159664/
1番目のセグメントファイルの件、開発途中版3で改善してました。ありがとうございます。
ただ、まだキャッシュ完了しない現象が5割くらいの確率で起きてます。
メッセージを見ている感じ、先頭のセグメントでIllegalBlockSizeExceptionが起きると完了にならない模様。
ソースもちょっとづつ読んでますが、まだまだ挙動がよくわからないです。
【開発途中版4 2024-03-17】

- シークなどで通信が中断された場合に1/16の確率で不完全な動画セグメントファイルが生成されていた問題を修正。
onTransferEnd(boolean completed)の引数を確認していないのが原因でした。
IllegalBlockSizeExceptionもこれが原因でした。
HlsCachingProcessor.javaを改変しながらコードを書いた時にcompleted引数には触れてないから役割が分かってなかった。
Hlsでは受信バイト数をカウントして完了したかどうかを見ていたから触れてないのだった。

- 未知のセグメントを受け取った場合にプレイリストを再スキャンする機能を追加。これによってキャッシュコンプリート処理不発を改善した。
原因は分からないけど対処を追加しました。CacheManager.java#addCachedSegmentAndCheckComplete
プレイリストが揃っていない状態でキャッシュ済セグメントを追加する要求なんて来るはずないんだけれども。
何か見落としている。

- showCachingオプションを追加。trueにすると"caching smXXX"というメッセージがセグメントを受信するごとに出ます(dmc-hlsはではまだ出ません)。デフォはfalse。
デバッグ用にログを仕込んでたんだけれどもリリース版でも欲しい機能だからオプションにしました。

- 数日使ってみて重大なバグがなければ、一般ユーザーにもNicoCacheを勧められる扱いにします。

- セグメント通信中に206(partial content)レスポンスや304(変更ナシ)が返ってくる。そんな要求はしていないはずなのに。とはいえ正常通信も来ているからこれらは致命的なエラーではない。

 >>/159667/
> ソースもちょっとづつ読んでますが、まだまだ挙動がよくわからないです。
大枠でいうとどこがわかりにくいです?
Hls処理の真似して書いているだけで自分もブラックボックスな理解がかなりあります。
変数にも関数にもクラスにも役割・目的・立ち位置はコメントに残すようにしているのだけれども、試行錯誤中で抜けてるところがあります。
今回になって値を運ばせるために一回ブラウザに送り出してから、またプロキシ側に値を戻すようなことをした(nicocachenl_domandcvikey)ので、後から読む人はきっと大変だと思う。

メモ。
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キャッシュが使える可能性が出来ました。
> NicoCache26 >8
> 開発途中版3と4を試してみたけど、キャッシュはおろか、ブラウザ上で再生すら開始されないかな
> 未キャッシュのだと、no cache found~でフォルダまでは作られるけど、同じく再生は出来ず。
> フォルダ内は、m3u8fileが出来てるだけ。 
全然だめか
・他にエラー出ていませんか
・キャッシュフォルダに入っているのはmaster.m3u8だけですか
 ・audio.m3u8やvideo.m3u8は入っていますか
 ・aduioフォルダやvideoフォルダはありますか

> キャッシュ済(mp4)のページだと、disable~ と出てその後「+++++++++」が出て、再生も開始されず。
そんなに+が繰り返される?
ニコニコ動画のプレイヤーは通信に失敗したりすると5回ほど再試行してから諦めるはずで、こっちが知っている挙動と違う

見当がつかないので後でデバッグメッセージを仕込んだバージョンを出します。

・クロスオリジン通信に関するコーディングミス(ありえるけどこっちでも再現するはず)
・configのmitmHostPortの設定ミス(再生不能になる。でもno cache foundまで到達出来ないはず)
・証明書の中途半端状態(動かないか、あるいは動いてもno cache foundまでは到達出来ないはず)
・CmafCachingProcessor.javaとDefaultRequestFilter.javaの不整合(可能性低い)
・仕様ABテストでユーザーごとに仕様が違う可能性(原因候補に入れる意味はない)
 >>/159669/
> 大枠でいうとどこがわかりにくいです?
とりあえず、16の倍数にならないのは01.cmfvの場合がほとんどのようなので、初期の通信が混ざってないかとか検証しようと思ってました。
しかし、通信が並行しているときの振り分け方とかがどうなっているのかが、全然わからない感じです。
まあ、Javaは昔Androidアプリを作るのに少し触った程度で、経験が足りないのもあると思いますが。
ちなみに、変数名がわかりやすいものに置き換わっていたりするのはいいですね。
プログラミングスレ乗っ取りみたいになっちゃったので別スレ立てました。
NicoCache関連は以降はこっちで。
 >>/159672/

若者がネットで見てるのも
テレビ番組の転載かテレビ番組のスタッフが作ってる動画
単に受像機で見るかどうかの差でしかない
令和6年1月1日16時10分頃の石川県能登地方の地震について
https://www.jma.go.jp/jma/press/2401/01a/202401011810.html

最大震度7
https://okwave.jp/qa/q10215094.html
世代間対立を煽ってしまっているのはこの方自身では?

人にさわさわ触られるのは気持ちいいけど揉むのも揉まれるのも気持ち悪くならない?

9/6水 下水を流れるウンチを見れば第9波の到来がわかる!? コロナの感染拡大を"見える化"する「下水疫学」の世界

検査有料化などで検査を受けない人が増えたため、今は、感染者数は低く出てあてにならない。しかし、下水はその影響を受けず比較できる。今は過去最悪級である
https://wpb.shueisha.co.jp/news/society/2023/09/06/120578/



南瓜任務にウィークリーがあることに今気付いた
…まあ徹甲弾の分さえ確保できればセーフだろ
thumbnail of 保有×10.png
thumbnail of 保有×10.png
保有×10 png
(322.34 KB, 392x392)
改修に使いそうで使わないちょっと使う素材
そろそろ倉庫を圧迫してきたが用意するのがめどいので捨てられず…
thumbnail of アニメで脳を焼いてきたやつ.png
thumbnail of アニメで脳を焼いてきたやつ.png
アニメで脳を... png
(329.7 KB, 390x390)
瑞雲の改修どうしようかな
戦力的には改二★10に留めるべきなんだけど夜間瑞雲3機目以降を作りたい
三隈改二のスペックと関連任務待ちかなぁ

地方の魅力発信や観光分散といわれている時代には一極集中も合わないんでしょうね。
日大生「出身は日本大学卒です!」
京都人「立派な大学どすわぁ」
大阪人「日大?アホやがなガハハハ!!www」

正直大阪人の方が好感持てるよなこれなら

Post(s) action:


Moderation Help
Scope:
Duration: Days

Ban Type:


New Thread
Max 20 files0 B total
Refresh

Page: Prev [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] Next | [Index] [Catalog] [Banners] [Logs]