diff options
| author | wm4 <nfxjfg@googlemail.com> | 2015-10-20 12:17:21 +0200 |
|---|---|---|
| committer | wm4 <nfxjfg@googlemail.com> | 2015-10-20 12:17:21 +0200 |
| commit | de1b1a7da9e6ddf42447271e519099a88b389e4a (patch) | |
| tree | 9e7e04924ab14e733f66fd729a05dc451f0ee840 /COPYING.GPLv2 | |
| parent | 35564318ad5a679afed14a1c88b517aa2d21298d (diff) | |
| download | ffmpeg-de1b1a7da9e6ddf42447271e519099a88b389e4a.tar.gz | |
avformat/mp3dec: improve junk skipping heuristic
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.
Diffstat (limited to 'COPYING.GPLv2')
0 files changed, 0 insertions, 0 deletions