On Mon, Feb 26, 2018 at 3:07 PM, Michael Niedermayer <mich...@niedermayer.cc > wrote: > > The way parsers are intended to work (that is years ago and i dont remember > that there was a proposal to change this) > is to never drop data. Thats how the stuff was intended to work. > > On top of that it was sometimes convenient to just drop data in a Parser, > or > a Parser was sloppy implemented and unintentionally looses data. > > To awnser the above question, i dont think the mp3 parser can just be > changed > alone. As other code like for example muxers depend on some tags being > discarded. > So any change has to be done with some care. > > not specific to just mp3 but all parsers, > droping data the parser does not understand is bad though. > it can be an extension that some decoders could use > it can be damaged data that a decoder can partly recover and improve the > output > it can be some data that is invalid in that location (like midstream > metadata > changes in some formats) but that still contains valuable data and that > would > be lost even if the components downstream in a player are able to > interpret it. > > Thus for me droping data in a parser is something that i prefer to avoid. > Unless "not droping" would cause noticably more problems ... > > Thanks for the information. I agree that seems reasonable, but is a significant API change to the current system that, as you note, extends beyond just the mp3 parser. It's certainly outside of the scope of things I can sign up for at this time. While I feel my patch is a strict improvement (more consistent) that fits with the current design, we can maintain this in Chromium if you'd rather not accept it.
- dale _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
