Total playback time is abnormally long when running in Safari / Safariで処理すると総再生時間が変
Closed this issue · 39 comments
test-13.mp4
Safariで作ったmp4
とりあえずIssueを出してみた gpac/mp4box.js#355
でもworkerではない処理系の時は普通に時間合ってたんだよな
でもworkerではない処理系の時は普通に時間合ってたんだよな
でもなんか異常なので今の実装の方が正しいのかも
(ところで: Chromeで処理した動画が2倍で済んでてSafariで処理した動画はめっちゃ長い理由を理解していない)
mfra/tfra/mfroを書いてみたけど解決しなかった
ffmpegのソースを読めば原因が分かりそうだけどパッと検索した限り端緒を見つけられなかった
While processing ffprobe
, open_input_file()
calls avformat_find_stream_info()
to correct information then calls av_dump_format()
to output.
avformat_find_stream_info()
calls estimate_timings()
.
estimate_timings()
is most relevant for calculating duration, conditionally branching and calling lower level functions.
r_frame_rate
がおかしくて、これによって色々ダメなことが起きてるらしい
ログによれば max_analyze_duration に引っかかってるっぽい
いや結局それってtime_baseがおかしいので(?)ffmpegの内部durationが滅茶苦茶になっているだけだよな
VideoEncoderで指定してやらないとdescriptionのSPSのフレームレートが変になって、そいでもってtime_baseがおかしくなるのか
残念ながらVideoEncoderにframerateを設定しても変わらん
(最後のPPSが変わってないからいいじゃんと勘違いしていたけど、関係あるのは真ん中のSPSだったわ)
SPSのパース
timing_info_present_flagがあったらここでframerateとして記録している?
timing_info_present_flagがあったらここでframerateとして記録している?
av_reduceは引数2, 3を約分し(reduce)て引数0, 1(ポインタ渡し)に代入するという感じらしい
これの起動の仕方に15分悩んでたけどコマンドに-debug pict
を付け足せばいけた
r_frame_rateは主にff_rfps_calculateが決定してそうだけど解読が億劫
睡眠を経て開いたら何をやってたかわからなくなったが結局SPSをいじってnum_units_in_tick/time_scaleを突っ込むのが手っ取り早い気がしていたのは覚えている
SPSをいじらなくてもVideoEncoderのconfig.decoderConfig.descriptionがtiming_info_present_flag=1にしてくれれば済む件
つかedts/elstのmedia_timeを参考にしてくれれば悩むことないんだけどそういうふうに仕向けられないかしら
少し調べてみたところ、こちらはtransform.tsで最終フレーム付近のフレームのソートが正常にできていないことが根本的な問題のようです
エンコードした後のtimestampが順番通りでなく出てきてるんだわこれ
EncodedVideoChunkはソートしてはいけないのでうーん
durationをsortの時点で付与するかしら
transform.tsで最終フレーム付近のフレームのソートが正常にできていない
ばちくそ根本的な処理がまちがってました…