> Am 03.07.2018 um 22:29 schrieb Carl Eugen Hoyos <ceffm...@gmail.com>: > > 2018-07-03 22:25 GMT+02:00, Karsten Otto <ott...@posteo.de>: > >> It took a closer look at what happens when I hear a BLEEP: The packet begins >> with a partial frame, starting with the byte sequence "ff ee 47 9d“. >> Unfortunately, >> the mp3 parser indeed accepts this as a valid mp3 header, causing the noise. >> By looking for the more restricted header, my patch finds the real next >> frame at >> offset 78. >> >> BTW: Should this sequence actually pass? AFAIK 01 is not a valid MPEG audio >> version ID? > > The parser is not supposed to drop data. > Does this mean the demuxer is responsible for finding the proper frame start? In that case I should keep my patch 3/3. But Michael Niedermayer indicated this is bad because the demuxer should not be concerned with codec specific things. I am confused :-/
> Carl Eugen > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
