Hi Karsten, I believe that the parsers are seek-unaware, so you're expected to delete and recreate (or reinit) the parsers after each seek.
Ronald On Sun, Jun 17, 2018 at 10:56 AM, Karsten Otto <ott...@posteo.de> wrote: > Hi list, > > I have a question about mpegaudio_parser. I see that it keeps any packet > data before a frame header, instead of discarding it. This makes sense, > because it usually can combine this data with the leftovers from a previous > packet to complete a frame. But the parser also does this when just > starting up, i.e. after a seek. I had expected it to discard the preceding > data in this case. So, is this expected behaviour? Am I using it wrong? > > Background: I am trying to add seek capability to libavformat/aadec. > Unfortunately, when the format contains MP3 content, its frames do *not* > align with the internal crypto chunk boundaries. So when seeking to a valid > chunk start, it usually lands in the middle of an MP3 frame. Given the > behaviour of the mpegaudio_parser, there is always some audible glitch. I > can work around this by adding my own MP3 header detection, but that would > not be very DRY. So, what is the proper way of handling this case? Any > suggestions? > > Thanks, > Karsten > _______________________________________________ > 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