facebook twitter hatena line google mixi email
★お気に入り追加


  • 1
  •  
  • 2025/03/28(金) 14:15:45.27
!extend:checked:checked:1000:512:donguri=2/3
!extend:checked:checked:1000:512:donguri=2/3

スレの立ちにくい板なのでスレ立てを優先します VIPQ2_EXTDAT: checked:checked:1000:512:donguri=2/3: EXT was configured

ここまで見た
  • 240
  •  
  • 2025/04/27(日) 03:52:44.46
>>235
Windows版のStreamlink 7.2.0で--ffmpeg-copyts falseというコマンドオプション通る?
Command-Line Interface見ても --ffmpeg-copytsをつけるかつけないかのオプションで--ffmpeg-copytsの後ろにboolを指定できるオプションではなさそうなんだけど
--ffmpeg-copyts
Set the -copyts FFmpeg option, so input timestamps won't be processed and the initial start time offset value be kept.

URLがエラーで書き込めない略すけど実際に以下のコードで試してみたけどエラーになる
streamlink.exe 放送URL 288p_alt -o test.ts --ffmpeg-copyts false
streamlink.exe 放送URL 288p_alt --ffmpeg-copyts false -o test.ts
こっちは動く
streamlink.exe 放送URL 288p_alt -o test.ts
streamlink.exe 放送URL 288p_alt --ffmpeg-copyts -o test.ts

ここまで見た
  • 241
  •  
  • 2025/04/27(日) 04:34:59.69
今のnicolive.pyってこうやってコメントアウトされてるけどこれでも
ffmpeg-copytsが適用されるの?
# ffmpeg_options={"copyts": True},

ここまで見た
  • 242
  •  
  • 2025/04/27(日) 05:08:47.69
>>240
ごめんちゃんとコード見たらffmpeg-copytsは上書き対象じゃなかった
許して

ここまで見た
  • 243
  •  
  • 2025/04/27(日) 10:23:19.10
>>241
それは>>41のレスみて自分でnicolive.pyを修正したと思われるけど
#でコメントアウトされててその行は無視されるからffmpeg-copytsは適用されてないよ
自分でコマンドに--ffmpeg-copytsを追加しない限り

>>242
やっぱそうだよね
勘違いじゃなくてよかった

ここまで見た
  • 244
  •  
  • 2025/04/27(日) 19:30:04.13
>>243
だから適用されてないんだよね?必要ならStreamlinkを動かす時に自分で--ffmpeg-copytsをつければいいだけじゃないの?

ここまで見た
  • 245
  •  
  • 2025/04/27(日) 22:46:02.56
以下は全部同じ意味でffmpegにcopytsオプションを渡さない設定になります

1.
ffmpeg_options={"copyts": False}, [SlNicoLiveRec V1.0.1.2のnicolive.py]

2.
# ffmpeg_options={"copyts": True}, [>>41]

3.
ffmpeg_options={"copyts": True}, の行そのものを削除

ここまで見た
  • 246
  •  
  • 2025/04/27(日) 23:07:47.02
>>244
>だから適用されてないんだよね?必要ならStreamlinkを動かす時に自分で--ffmpeg-copytsをつければいいだけじゃないの?

その通り
Streamlink単体で使ってる人ならnicolive.pyを>>245の手段で変更し、それで音ズレしてたら--ffmpeg-copytsをつけて録画しなおせばいい

ここまで見た
  • 247
  •  
  • 2025/04/28(月) 00:29:21.62
わいはいつの間にか自分で直してたのか、、確かにnicolive.pyはちょっといじってるw

配布されてるnicolive.pyって元々は指定が無くて改めてつけてもらったものなのか、面倒だね
そもそも今のSINicoLiveRecで問題が起こってる人ってどれくらいいるんだろう

ここまで見た
  • 248
  •  
  • 2025/04/30(水) 10:50:23.41
nnn-revo2012の性格は嫌いだが実際に各ツールのために動いてくれてるの事実
そこは評価してるよ

ここまで見た
  • 249
  •  
  • 2025/05/01(木) 18:32:11.91
性格悪い分を能力や仕事から査定がきっちり引かれるだけの話だな

ここまで見た
  • 250
  •  
  • 2025/05/01(木) 23:14:36.12
こっちで先行
音ズレの件の調査中ですがだいたいわかってきたので

◆公式放送
・旧サーバーデーター変換配信および新サーバー移行後配信全て:FFmpegにcopytsオプションつけるつけないに関わらず音ズレなし

◆チャンネル放送
・旧サーバーデーター変換配信:FFmpegにcopytsオプションをつけると音ズレする
 FFmpegにcopytsオプションをつけないと音ズレしない
 上記配信は2025年3月中旬以前の配信
・新サーバー移行後配信:FFmpegにcopytsオプションつけるつけないに関わらず音ズレなし
・新サーバー移行後配信(スマホ配信):FFmpegにcopytsオプションをつけないと音ズレする配信がある
 チャンネル放送でスマホ配信はほぼないが可能性は0ではない

◆ユーザー放送
・旧サーバーデーター変換配信:FFmpegにcopytsオプションをつけると音ズレする
 FFmpegにcopytsオプションをつけないと音ズレしない
 上記配信は2025年2〜3月中旬以前の配信(ユーザーにより移行時期が違う)
・新サーバー移行後配信:FFmpegにcopytsオプションつけるつけないに関わらず音ズレなし
・新サーバー移行後配信(スマホ配信):FFmpegにcopytsオプションをつけないと音ズレする配信がある
 配信者がスタートするタイミングによるが全ユーザー放送の5%ぐらいではないかと思われる

ここまで見た
  • 251
  •  
  • 2025/05/01(木) 23:17:07.10
>>250
◆結論
・チャンネル・ユーザー放送は旧サーバーデーター変換配信をDLしないのであればFFmpegに常にcopytsオプションをつける設定でよい
 (SINicoLiveRecV1.0.1.1以前のバージョンおよびStreamlink 7.3.0(nicolive.py無修正)
・ユーザー放送はcopytsをつけないと逆に音ズレする配信があるので注意
 (SINicoLiveRecV1.0.1.2で発生)
・公式配信はどちらでもいい
・旧サーバーデーター変換配信はチャンネルは9月半ば、ユーザーは5月中には期限切れになるのでStreamlinkのnicoliveプラグインの修正をわざわざ依頼する必要性はないと思われる
・当面SINicoLiveRecで常時copytsを出力するようにして音ズレするときだけcopytsを出力しないオプションを作成して対応するのが良いかと思われる
・Streamlink 7.3.0(CUI版)は必要なら各自でnicolive.pyを修正(旧サーバーデーター変換配信をDLする場合のみ)

ここまで見た
  • 252
  •  
  • 2025/05/02(金) 09:09:47.33
・SlNicoLiveRecでcopytsのオプション設定できるようにする
 デフォルト値はV1.0.1.2とは逆のTrue、外せるようにもする
 外部から引数で渡せるようにするかどうかは議論の余地あり
ってところか…
accessRightMethodについてはすでにsingle_cookieが適用されてるし大丈夫そうだね
元々Streamlinkを直で使ってる人は自分でnicolive.pyは修正するくらいできるだろうし

SINicoLiveRecじゃなくてSl(L)NicoLiveRecね、俺も最初はIだと思ってたけどw

ここまで見た
  • 253
  •  
  • 2025/05/02(金) 12:15:02.52
>>252
四八福星間開発氏にはこういうリクエストだすつもり
--------------------------
次にSlNicoLiveRecをバージョンアップする際に以下の機能を追加していただけないでしょうか?
・音ずれ修正機能(チェックボックス)
 設定→上級者設定に以下の項目を追加する
 音ずれ修正
 [ ]音ずれしている放送を音ずれ修正して録画する
 通常は必ずオフにしてください
 ユーザーやチャンネルの一部の放送で音ずれする場合だけチェックオンにして録画してください
※イメージ
//i.imgur.com/u0tYwjY.jpg

チェックがオンの場合はStreamlinkの引数に --ffmpeg-copyts を*つけない*
チェックがオフの場合はStreamlinkの引数に --ffmpeg-copyts を*つける*
デフォルトの設定はオフです
※ちょっとややこしいのですが、現状のニコ生の仕様や--ffmpeg-copytsの仕様によりこうするのが一番良いと判断しました

ここまで見た
  • 254
  •  
  • 2025/05/02(金) 12:17:50.50
>>252
>accessRightMethodについてはすでにsingle_cookieが適用されてるし大丈夫そうだね
streamlink本家はまだ未対応ですが、しょうがないので自分がIssue書いて本家に対応してもらう予定

ここまで見た
  • 255
  •  
  • 2025/05/02(金) 12:31:12.90
>>251 案としては
・--ffmpeg-no-copytsのようなオプションを新たに追加してもらう
・nicolive.pyの中で放送がユーザー放送だった場合のみcopytsをつけるように変更する
・nicolive.pyの中でニコ生独自のオプション--nico-ffmpeg-copyts=true/falseみたいなオプションを追加してもらう
・nicolive.pyの中で一度m3u8を読み込んで先頭にblankがありなおかつ映像と音声のblankの時間に差がある場合のみcopytsをつけるように変更する

というのもありますが、技術英語もバリバリの人ならどれでもいけると思いますが自分は無理っす
(やりあえる人がいるならやってください)

それとyt-dlpが更新されてますが、こっちの修正者はおそらく公式ぐらいしかみてないようで(モバイル配信の)ユーザー放送はまったく使い物になりません
なのでyt-dlpはユーザー生のモバイル配信のTSの件から始めないといけないですね これまた面倒(自分はやる気ない)

ここまで見た
  • 256
  •  
  • 2025/05/02(金) 16:52:16.22
>>253
「音ずれ修正機能」の案、ユーザーから見るとちょっと紛らわしいかもって思った
理由としては
・「修正」って名前が紛らわしい: 「音ずれ修正」って名前は、いつでもオンにしとけば大丈夫な、万能な解決策だって誤解されやすい
・チェックボックスのオンオフが逆: チェックボックスをオンにするのに、裏側では特定のオプションが無効になるっていう動きが直感的じゃない
・デフォルトがオフで混乱: 現状のニコ生はcopytsをつけておくのがベストだから、デフォルト設定はこの機能がオフになるようにしないといけない。それが「なんで修正機能をオフにしとくの?」って疑問とか混乱のもとになる
・ユーザーが困る、問い合わせが増える: こういう分かりづらさがあると、ユーザーが設定を間違えて録画が失敗したり音ズレしたりして、結局質問がいっぱい来る原因になる可能性がある


項目名: 音ズレ対策
ラベル:現在のニコ生形式に合わせた処理を有効にする
説明:
現在のニコ生形式に合わせた音ズレを防ぐための重要な設定です
基本的にチェックはオンのままご利用ください
ごく一部の特殊な放送で音ズレする場合のみオフにしてください

自分がリクエスト出すわけじゃないし出すつもりもないし
あくまでも個人的な意見だから全く採用しなくてもいいよ

ここまで見た
  • 257
  •  
  • 2025/05/02(金) 16:54:18.94
>>256
デフォルトはチェックオンで

ここまで見た
  • 258
  •  
  • 2025/05/02(金) 19:07:14.06
yt-dlp 2025.04.30
このアプデは>>35が正式に組み込まれただけで>>35から特に変更はない
まだ普通に使うのは無理がある感じだから詳しくないならdlpでのニコ生新配信DLは当面諦めたほうが良い

ここまで見た
  • 259
  •  
  • 2025/05/02(金) 21:54:45.27
ド素人だからSlNicoLiveRecに任せるわ

ここまで見た
  • 260
  •  
  • 2025/05/03(土) 02:04:29.53
SlNicoLiveRecをV1.0.1.3に更新
//person-of-ehomaki.blog.jp/archives/38458362.html

前のバージョンV1.0.1.2って1400近くDLされてるな
SlNicoLiveRec1012.zip 25/04/18 20:43 1396

ここまで見た
  • 261
  •  
  • 2025/05/03(土) 02:16:12.16
>>256
そういう意見もあるんであれば無駄にややこしくなるんでこのまま放っておきますわ
nicolive.pyはaccessRightMethod以外の変更はなしのリクエストは出しときますが、過去のタイムシフトをダウンロードする人なんてほぼいないと思うし今年の10月には音ズレするチャンネルTSもなくなるんで

ここまで見た
  • 262
  •  
  • 2025/05/03(土) 02:51:32.47
>>250
◆結論(2025/5/3版)
・チャンネル・ユーザー放送は旧サーバーデーター変換配信をDLしないのであればFFmpegに常にcopytsオプションをつける設定でよい
 (SINicoLiveRecV1.0.1.1以前のバージョンおよびStreamlink 7.3.0(nicolive.py無修正)
・ユーザー放送はcopytsをつけないと逆に音ズレする配信があるので注意
 (SINicoLiveRecV1.0.1.2/V1.0.1.3で発生)
・公式配信はどちらでもいい
・旧サーバーデーター変換配信はチャンネルは9月半ば、ユーザーは5月中には期限切れになるのでStreamlinkのnicoliveプラグインの修正をわざわざ依頼する必要性はないと思われる
・SINicoLiveRecはnicolive.pyをaccessRightMethodの追加以外元に戻すようリクエストを出す
・旧サーバーデーター変換配信をDLする場合はSINicoLiveRecV1.0.1.2/V1.0.1.3を使うか、各自でnicolive.pyを修正する

ここまで見た
  • 263
  •  
  • 2025/05/03(土) 09:38:22.32
SlNicoLiveRecをV1.0.1.4に更新
//person-of-ehomaki.blog.jp/archives/38480288.html

更新内容
録画開始時に「録画終了予定時刻を過ぎています。」と表示されて録画できない不具合を修正
nicolive.py を変更
・リアルタイム録画の通信モード「安定性重視」に変更
・常に--ffmpeg-copytsオプションを渡す(ユーザー生放送のアプリ配信の一部で音ズレする対策)

ここまで見た
  • 264
  •  
  • 2025/05/03(土) 09:45:33.50
音ズレの件は時間が解決してくれるということで僕はこれで終わり
後追っかけ再生録画したいとか長時間配信してると途中で切れるとか録画時に自動予約など録画ツール(仮にあったがStreamlinkにはない機能については直接Streamlinkの方を修正しないといけないのでIssue書いてStreamlinkのメンテナーさんにお願いするしかないですね
それは機能が欲しい方が各自で要望してください

ここまで見た
  • 265
  •  
  • 2025/05/04(日) 04:22:00.62
SINicoLiveRecV1.0.1.2を使ってる人向け
このバージョンだけサーバー移行後の配信もユーザー生(とチャンネルの一部)放送で音ズレが発生すると思います
SINicoLiveRecV1.0.1.2は1400ぐらいダウンロードされてて今ほとんどの人がこれ使ってると思いますが、特にユーザー生放送中心の人は最新版(SINicoLiveRecV1.0.1.4)にアップデートした方が良いと思います

ちなみに僕が書くところの「アップデートした方が良いと思います」は「アップデートしないと必ず音ズレするからアップデートしとけ!」という意味なのでよろしくおねがいしま〜すw
公式やチャンネルしか見ない(録画しない)人はどれ使ってもほぼ音ズレしないので別にアップデートしないくてもいいです(お好みでどうぞ)

ここまで見た
  • 266
  •  
  • 2025/05/04(日) 05:57:22.31
何をそんなにごちゃごちゃ書いてるのかわからんのだが普通の人は最新の使ってたら良いの?

ここまで見た
  • 267
  •  
  • 2025/05/04(日) 08:46:57.45
>>266
普通の人が何かわからんが、ユーザー生放送をDLするかしないかで変わる
ユーザー生放送をDLするならSINicoLiveRec最新版必須(またはSINicoLiveRecV1.0.1.1のままでも良い)
そうじゃない人はどれでもいい それだけ

ここまで見た
  • 268
  •  
  • 2025/05/04(日) 09:04:03.41
>>266
ユーザー生放送しか見ない人にとってはユーザー生放送を見てる人が”普通の人”だろうし
チャンネル放送しか見ない人にとってはチャンネル放送を見てる人が”普通の人”だろうし
公式放送しか見ない人にとっては公式放送を見てる人が”普通の人”だろうから
その人の立場によって”普通の人”がかわるんじゃないかね?

もっといえば世間一般の”普通の人”はニコニコ生放送なんてみてないからそもそもSINicoLiveRecなんていらないだろ

ここまで見た
  • 269
  •  
  • 2025/05/04(日) 15:10:10.68
めっちゃごちゃごちゃ書くやんw
もういいよ最新使うわ

ここまで見た
  • 270
  •  
  • 2025/05/05(月) 01:10:50.16
よく分からない人は最新版でいいよ

ここまで見た
  • 271
  •  
  • 2025/05/05(月) 02:16:58.97
ていうか最新版にしない理由あるん?

ここまで見た
  • 272
  •  
  • 2025/05/05(月) 03:54:04.41
アップデート=新たな不具合の発生=余計な手間の発生という事実を認めない馬鹿が発狂する

ここまで見た
  • 273
  •  
  • 2025/05/05(月) 04:43:30.80
わからない人向け
・V1.0.1.4(またはそれ以降の最新版)に更新する
・nicolive.pyは変更しない(わかる人のみ自己責任で)
・5chやこの掲示板に書かれている変更は日々変わっていくので特に最初の頃の情報は不要になっていることが多い

ここまで見た
  • 274
  •  
  • 2025/05/05(月) 06:39:04.42
最新のに更新したらなんかファイル名エラーで落ちるようになったやんけ・・・

ここまで見た
  • 275
  •  
  • 2025/05/05(月) 07:23:49.91
>>274
四八福星間開発のブログで報告どうぞ
その手はファイル名に使えない文字が入ってるからだと思うんで、必ずファイル名のフォーマットや放送IDも一緒に報告すること
これはこの手のツールあるあるのお約束だな

ここまで見た
  • 276
  •  
  • 2025/05/05(月) 07:44:19.35
使えない文字というか標準から何も変更してないんだけど、みんなは使えてるのかな
別に自分なりのファイル名とかにしてるわけじゃない

ここまで見た
  • 277
  •  
  • 2025/05/05(月) 07:55:01.72
>>276
あなたがたまたま録画したい配信者のタイトルや名前なりに以下の文字が入ってて、Slなんちゃらはそれを変換してなかったらエラーになるかも
じゃあなければStreamlinkにファイル名を渡した際にエラーになるのかもしれない
どっちにしろここにかいてもどうにもならんので四八福星間開発のブログで報告しないと変わらない

参考 livedlの禁則文字変換
func ReplaceForbidden(name string) (fileName string) {
fileName = name
fileName = regexp.MustCompile(`\\`).ReplaceAllString(fileName, "¥")
fileName = regexp.MustCompile(`/`).ReplaceAllString(fileName, "∕")
fileName = regexp.MustCompile(`:`).ReplaceAllString(fileName, ":")
fileName = regexp.MustCompile(`\*`).ReplaceAllString(fileName, "*")
fileName = regexp.MustCompile(`\?`).ReplaceAllString(fileName, "?")
fileName = regexp.MustCompile(`"`).ReplaceAllString(fileName, `゛`)
fileName = regexp.MustCompile(`<`).ReplaceAllString(fileName, "<")
fileName = regexp.MustCompile(`>`).ReplaceAllString(fileName, ">")
fileName = regexp.MustCompile(`\|`).ReplaceAllString(fileName, "|")

fileName = regexp.MustCompile(`)`).ReplaceAllString(fileName, ")")
fileName = regexp.MustCompile(`(`).ReplaceAllString(fileName, "(")

fileName = regexp.MustCompile(`\p{Zs}+`).ReplaceAllString(fileName, " ")
fileName = regexp.MustCompile(`\A\p{Zs}+|\p{Zs}+\z`).ReplaceAllString(fileName, "")

// 末尾が.であるようなファイルは作れない
fileName = regexp.MustCompile(`\.\p{Zs}*\z`).ReplaceAllString(fileName, ".")

return
}

ここまで見た
  • 278
  •  
  • 2025/05/05(月) 08:09:55.95
>>277
すまん言い忘れたけど同じ放送を古いバージョンで録画したら問題無いんだ
なんか自分だけだったら悪いからわざわざ言うのもなと思って
しばらく様子見

ここまで見た
  • 279
  •  
  • 2025/05/05(月) 08:37:23.82
>>278
>すまん言い忘れたけど同じ放送を古いバージョンで録画したら問題無いんだ
なら3か4で追加された機能の中にバグがあるって特定できるからなおさら*今*報告しといた方がいい
こういうのって同じプログラマーじゃないとわかんねーかもな

ここまで見た
  • 280
  •  
  • 2025/05/05(月) 08:40:56.39
>>278
>しばらく様子見

そうされるとどれが原因かの特定が時間経つごとにわかりづらくなるから作者もユーザーにもメリットないね
それでも様子見なら前のバージョンずっとつかっとけばいいよ(ただしユーザー生放送録画する以外の場合ね)

ここまで見た
  • 281
  •  
  • 2025/05/05(月) 14:28:30.25
全般的に今の体制じゃ該当ID出さない限り放置だろうな
人居なすぎるので特定IDに関する問題は”そいつ”しか引っかかってない可能性が高い
何もしないで勝手に直るとか思わないほうが良い

ここまで見た
  • 282
  •  
  • 2025/05/05(月) 16:31:32.68
何の文字で引っかかってるか知らんが、もしその特定文字をその配信者しか使っておらず、かつその配信を自分1人しか録画してなかったとしたら、誰も気づかないしいつまで経っても直らないぞ
自分にしか該当しなくて誰も気づいてないってことは、フリーソフトはまれにある

ここまで見た
とりあえずIssue書いた
たった1行追加するだけなのになあ

ここまで見た
>>283
>些細な変更です…変更が必要で正しく動作していることを証明する一致するデバッグログを添えて、プルリクエストを出してください。

無理だ・・・

ここまで見た
>>284
一応理由を書いておいたけど、これは無理(Issue取り下げ)かなってことで
めんどくさすぎるやん!!!!

yt-dlpの方はそもそもcopyts対応してなさそうだしblank削除もしてないしユーザー生はまったく使い物にならない
今出てるpull requestも進まなそうだしお前らこれでいいのか?

ここまで見た
  • 286
  •  
  • 2025/05/05(月) 21:41:03.14
>>278
こいつが言い出しっぺなのに
恥ずかしい放送録画しててIDを晒したくないんだろ

ここまで見た
そもそもAES128暗号化はDRMじゃねーから問題ないってことならゲストさん(録画ツールの作者)および自分も動画DLやめてねーから
ニコ動も同様でほとんどのツールは動画のDL辞めてるし

ここまで見た
>>287
取り下げました
残念無念・・・

ここまで見た
  • 289
  •  
  • 2025/05/05(月) 22:25:59.71
Issue見たけど法規制云々の前にそもそもブラウザとの同時視聴で切断される事を
書いてないから変更の必要性が伝わってないんじゃね

ここまで見た
>>289
>法規制云々の前にそもそもブラウザとの同時視聴で切断される事を
>書いてないから変更の必要性が伝わってないんじゃね

それはニコ生本来の仕様じゃないし、残念なことにそれを適切に伝える英語力がないんでもう無理っす
心折れました

ここまで見た
これ保存版ねw
ニコニコは(動画、生放送、静画)含めて表示するブラウザやスマホetcをは1つのデヴァイスとしてとらえてる
具体的にはヘッダーの X-Frontend-Id が同じかどうかで判断してて、同じ X-Frontend-Id があればどっちかが切れる仕様


ブラウザ: 9
Androidアプリ: 90
Androidブラウザ: 91
※iPhoneアプリ、iPhoneブラウザの値はiPhone持ってないので知りませんw(おそらく90/91だと思うけどわからん)

で、各ツールは以下のように指定されてるので X-Frontend-Id が同じならどっちかがきれるのが本来の仕様
でも今回のサーバー移転で X-Frontend-Id が同じでもcookieが同じなら切れなくなったのは新仕様なのか単なるポカミスかなんなのかはわからん

(仮: 90(デフォルトの場合)
livedl: X-Frontend-Id無指定
Streamlink/yt-dlp: 9

フリックゾンビ
フリックラーニング
ここまで見た

★お気に入り追加

このページを共有する
facebook twitter hatena line google mixi email
おすすめワード