search

AkarinVS / L-SMASH-Works

Works based on L-SMASH project; This repo focuses on the common portion and the VapourSynth plugin. AviSynth users please use https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works. ffmpeg 5.0+ please use ffmpeg-4.5 branch.
47 stars 11 forks source link

incorrect video seek for certain m2ts #19

Closed AkarinVS closed 2 years ago

AkarinVS commented 2 years ago

sample: KIXA90240/BDMV/STREAM/00000.m2ts (md5sum a508b825171a843a15dcb5a7c882f6ef) There are more cases, mostly in older BDs.

lsmas consistently fails to decode frame 351 (P frame) and more.... However, it can decode that frame correctly after remuxing the m2ts as mkv. (ffms2 also exhibits similar problems with the m2ts file.)

Note: this is a severe issue for affected video files because not only does it affect random seeking, it might also affect vspipe-based encoding (as VS R54 can't guarantee strict sequential frame accesses under all circumstances.)

AkarinVS commented 2 years ago

Not yet fixed. sample: KIXA90240/BDMV/STREAM/00003.m2ts, frame 2150.

again, current lsmas vA.3h release and ffms2 both failed to correctly decode this frame (when randomly accessed). This time, remuxing the video into mkv does not help.

Frame 2148 (IDR) and 2149 (I) are both I frames with 2149 labeled with recovery point SEI as a valid random access point (with exact_match_flag=1). Frame 2150 is a P frame referencing both 2148 and 2149, making 2149 not a valid random access point. Compounding this issue is that, 2148 is not a valid random access point either because it lacks its own SPS and PPS.

Even though one can argue that this input might be an incorrectly encoded file, this issue is serious enough that we have no choice but to somehow build a workaround.