On Tue, 20 Oct 2015 02:12:00 +0200 Michael Niedermayer <mich...@niedermayer.cc> wrote:
> On Mon, Oct 19, 2015 at 11:12:03PM +0200, wm4 wrote: > > Commit 2b3e9bbfb529e6bde238aeb511b55ebe461664c8 caused problems for a > > certain API user: > > > > https://code.google.com/p/chromium/issues/detail?id=537725 > > https://code.google.com/p/chromium/issues/detail?id=542032 > > > > The problem seems rather arbitrary, because if there's junk, anything > > can happen. In this case, the imperfect junk skipping just caused it to > > read different junk, from what I can see. > > > > We can improve the accuracy of junk detection by a lot by checking if 2 > > consecutive frames use the same configuration. While in theory it might > > be completely fine for the 1st frame to have a different format than the > > 2nd frame, it's exceedingly unlikely, and I can't think of a legitimate > > use-case. > > > > This is approximately the same mpg123 does for junk skipping. The > > set of compared header bits is the same as the libavcodec mp3 parser > > uses for similar purposes. > > --- > > Now compares less header bits, as requested. > > --- > > libavformat/mp3dec.c | 28 +++++++++++++++++++++------- > > 1 file changed, 21 insertions(+), 7 deletions(-) > > LGTM > > thanks > > [...] Pushed, thanks. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
