[FFmpeg-devel] FLAC parser inefficiency

Uoti Urpala uoti.urpala
Thu Dec 9 21:33:39 CET 2010


On Thu, 2010-12-09 at 21:01 +0100, Reimar D?ffinger wrote:
> On Thu, Dec 09, 2010 at 08:30:34PM +0200, Uoti Urpala wrote:
> > "Turn a data stream starting at an arbitrary point into one that can be
> > decoded without errors" is a use case that should be supported by
> > parsers (at least where reasonably possible - for formats like video
> > with inter-frame dependencies dependency errors could be hard to
> > completely avoid). If the parsers fail to indicate whether the initial
> > packet is considered junk or not then the best available solution is
> > probably to always discard the first packet output by a parser. But
> > that's clearly not optimal (when considering what the parsers _could_
> > do), as it can lose valid audio when there was no junk.
> 
> Doing it in the parser will only solve the problem half-way.
> You still have the same issue for e.g. formats that do not need
> a parser but do not (or not always correctly) mark keyframes.

That's another problem, but IMO its existence does not change the fact
that the parser behavior is unsatisfactory. It should be possible to
turn an arbitrarily cut data stream into a valid one by using the
parser. Most audio formats do not even have separate keyframes; the
functionality available for those should not be limited by the existence
of different formats.

> You can assume the decoder can detect broken data, if it's
> any worse at that than the parser it's broken.
> The "only" thing missing is either to disable any kind of
> error concealment etc. or (more flexible) let the decoder
> indicate which (if any) non-fatal errors it encountered.

All this is a lot harder to implement than a way for parsers to indicate
whether they already know the initial data is junk.

> Well, and some way to handle the error messages, but this can
> be handled with the log callback in principle, even if it
> is an inconvenient solution.

No, you can't handle this in the log callback alone. To determine
whether the message should be discarded you'd need to know whether the
packet was considered junk data, but if you already knew that it was
then you wouldn't have fed it to the decoder to begin with! At best you
could go from "always discard first packet" to "feed all packets to the
decoder but always discard all errors generated by the first packet".
This would be inconvenient and it still wouldn't be correct.




More information about the ffmpeg-devel mailing list