[FFmpeg-devel] mpegaudio_parser question
ottoka at posteo.de
Mon Jun 18 10:01:42 EEST 2018
I gathered as much, and indeed that is happening in libavformat/utils.c (seek_frame_internal with AVFMT_NOGENSEARCH in my case). But the mp3 parser keeps leading data even if freshly created. I was wondering why, maybe some codecs need it. Anyway, my question remains: What is a format supposed to do?
> Am 18.06.2018 um 00:58 schrieb Ronald S. Bultje <rsbultje at gmail.com>:
> 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.
> On Sun, Jun 17, 2018 at 10:56 AM, Karsten Otto <ottoka at 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
>> ffmpeg-devel mailing list
>> ffmpeg-devel at ffmpeg.org
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel