[FFmpeg-user] buffer underflow (?)

Paul B Mahol onemda at gmail.com
Fri Sep 29 18:00:52 EEST 2023


On 9/29/23, Mark Filipak <markfilipak.imdb at gmail.com> wrote:
> On Fri, Sep 29, 2023 at 10:38 AM Reindl Harald <h.reindl at thelounge.net>
> wrote:
>> Am 29.09.23 um 16:33 schrieb Mark Filipak:
>> > This is an ffmpeg architecture question, so I don't have a specific log.
>>
>> but you have real outputs
>>
>> > When concatenating involving only demuxing and muxing, I sometimes get
>> > "buffer underflow". Why underflow? It's not a real time process.
>>
>> you are long enough on the list to know that copy&paste of the whole
>> input/output is required
>
> Okay. I'll explain. When I tried
> ffmpeg -i "concat:c:\1.mp4|2.mp4 .."

That is simple concat at file level, it almost never works correctly.
Unless really streamed format is used, like mpegts.

> and that failed on "duplicate MOOV Atom", I converted the MP4s, 1: to
> MKVs, and 2: to MPEGs, and 3: to VOBs, and repeated with each of them.
> In one of them I got "buffer underflow".

Now I wonder what is wrong using concat demuxer.

>
> I woke up this morning -- I'm in the US -- asking myself, "buffer
> underflow? How is that possible?" I don't remember which of the
> concats: MKVs or MPEGs or VOBs, did that. So, I don't have a log. A
> log should not be required to ask: "How is a buffer underflow possible
> when it's not a real time process?"

Buffer overflow - something is too big in size. So  can not be put into buffer.
Buffer underflow - something is too small in size. So there is unused,
wasteful space left.
Also could mean decoder and/or demuxer did not processed whole buffer.

> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".
>


More information about the ffmpeg-user mailing list