Michael Niedermayer <[email protected]> added the comment: On Fri, Oct 30, 2009 at 11:12:17AM +0000, Alex Converse wrote: > >If you analyzed the bug, please explain a little more elaborately > >what the problem is, at least i dont know what it is purely from the > >mails in this thread > > > >Does the parser get stuck never resyncing to the correct syncwords? > > Simply put, the parser finds the ADTS syncword, passes the frame off to the > decoder, > jumps ahead the reported frame size, and looks for another syncword. Since > the > reported frame size is garbage, it is often likely that the next syncword > found is also false, and so the process repeats. Even
Yes but this should quickly converge to the true syncwords Its like when you have 4 fake syncwords and 1 correct in each kb, the 4 fake will lead to random forward movement the correct will stay correct. Assuming things are random the probabilty that one is wrong drops exponentially with each frame ... Of course one could do better by syncing on 2 ADTS headers instead of one ... though it does not appear to me that this would completely solve this issue ... > if it finds a good syncword some invariant stream parameters sent in the ADTS > header are set based on the first bad > frame. What if we have a stream that was damaged, that is the correct ADTS header has a few bits fliped? The code should IMHO either be able to update the invariant parameters or make very sure they are correct in the first place mp3 decoding has a similar problem, there its solved by only updating the supposedly invariant parameters after successfull decoding of a frame. And our mp3 parser requires several frames with invariant things identical before accepting the values. [...] ____________________________________________________ FFmpeg issue tracker <[email protected]> <https://roundup.ffmpeg.org/roundup/ffmpeg/issue999> ____________________________________________________
