2026.2.2
原因箇所について思い違いをしていた
まず全体長を知るためにProbe boundaryの条件をcanfastseekからcanseekに緩めた
この時ミスでSeekToTimeの条件までcanseekに緩めてしまった
これによってリモートファイルで正確なPCRベースシークを行うようになり、シークが激遅になった
これを防ぐためにSeekToTimeからシークロジックをガッツリ削った、するとシーク時に飛ぶ位置が長いファイルほどめちゃくちゃになった
31にそれに気づいて、SeekToTimeの条件はもとに戻した、でもシーク位置はおかしいまま
今日はシーク位置がおかしい原因がわかった
DEMUX_GET_POSITIONの挙動
全体長が取得できた時、全体長の長さを使って現在の位置を返す
取得できなかった時、バイトベースのシーク位置を用いて現在の位置を返す
これによって、全体長のありなしで取れるPositionが変わっていた
DEMUX_SET_POSITIONの挙動
全体長が取得できている時
かつcanfastseekの時、SeekToTimeによって正確に対象位置にシークする
かつcanseekのとき、SeekToTimeが失敗しバイトベースシークに移行する
全体長が取得できていない時
バイトベースシークを行う
なので、全体長が取れるがcanfastseekではないという状態になった時、全体長を使った時間ベースのpositionを使ってバイトベースシークを行ってしまうので大ズレする
Upstreamでは起きないので問題ない
対策としては
--ts-seek-percentを使いながらDEMUX_GET_LENGTHのブロッカーを消す
DEMUX_GET_POSITIONでcanfastseekのときだけ全体長の長さを使って現在の位置を返す
などがありそう
まあmpegtsはこれでいいかと思ったのだけど、じゃあmp4とかはどうなってんだろうと思ったら、めっちゃ壊れてた Upstreamが壊れてた
永遠に探索してる
誰もVLC 4.0.0-devでネットワーク越しのmp4見てないんだと思った
mkvとかならまあわかる気もするけど、mp4そんな壊れてることあるか？と思った mp4をpositionで移動していることがないから？
timeでも普通に壊れてたわ
3.xは普通に見れる
ts-seek-percentを使ってDEMUX_GET_LENGTHのブロッカー消してみて、なんかダメで、う〜ん
ログ出したらbyte-basedの場所は帰ってきてるので、Probeによってoffsetとu64が変わってるとしか思えないが、変わってるとしてどこで。。。