[FFmpeg-devel] [PATCH] mlp_parser: fetch a new timestamp when major sync is found

Hendrik Leppkes h.leppkes at gmail.com
Mon Mar 7 23:55:28 EET 2022


On Mon, Mar 7, 2022 at 6:10 PM Michael Niedermayer
<michael at niedermayer.cc> wrote:
> So why is this considered to be "ok" in audio codecs?
> Because we dont visually see that data is lost ?

This patch is not trying to argue that its "ok" to drop data, nor does
it introduce this behavior. Someone else did that years ago.

>
> but i dont think we should just build on top of this droping
> logic without some argumentation why this droped data can really
> not be used ever in any way (it may become harder to fix it the
> more is build on top)
>

There is no question that dropping the data inside a parser is not the
appropriate and documented behavior, but it is what it does, and what
it has done for ages.

Leaving an actual bug because some theoretical better fix might be
available is not rather productive, especially when the fix is one
short line - unless you actually provide said better fix in a
reasonable timeframe.
It is not adding the dropping behavior, that already existed afterall,
its just fixing the timestamp - in a rather trivial manner, too.

If you, or anyone else, wants to change the parsers logic to not drop
data, this patch does not hinder that in any way. It immediately fixes
the bug that was brought to my attention a while ago, that this case
breaks timestamps.
Dropping of data in front of a keyframe is another bug, even if they
are practically undecodable without some manual hackery, a parser
should not do that - but this patch does not even touch on that
behavior, other then mentioning it in the message.

- Hendrik


More information about the ffmpeg-devel mailing list