[FFmpeg-devel] [mpegaudio_parser] Skip trailing junk data when flushing parser.

[Michael Niedermayer]

On Mon, Feb 26, 2018 at 10:30:26AM -0800, Dale Curtis wrote:
> On Fri, Feb 23, 2018 at 7:01 PM, Michael Niedermayer <michael at niedermayer.cc
> > wrote:
> >
> > this goes the wrong direction.
> > Parsers should not discard data by default. The code we have for tags is a
> > hack.
> > There are many better ways to handle this.
> > Something similar to a AV_PKT_FLAG_CORRUPT set be the parser would be an
> > example. This could then optionally be discarded
> >
> 
> It's not just the trailing tags though, skipping bad data is fundamental to
> how this parser works. Even if we change it so that we mark the last packet
> corrupt, midstream the parser is still designed to skip over everything
> that doesn't look like an mp3 frame. I.e., the data between mp3 frames is
> just dropped wholesale.
> 
> Are you proposing we rework the mp3 parser entirely to not drop any data
> anymore or just not drop the trailing data?

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

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180227/3a966ea7/attachment.sig>