> Am 03.07.2018 um 22:29 schrieb Carl Eugen Hoyos <[email protected]>: > > 2018-07-03 22:25 GMT+02:00, Karsten Otto <[email protected]>: > >> 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 > [email protected] > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel _______________________________________________ ffmpeg-devel mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
