On Mon, Mar 7, 2022 at 6:10 PM Michael Niedermayer <mich...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
