I think you're right. Seems like the best solution is to maintain the
number of calls to matroska_deliver_packet(); patch modification on the way.
On Wed, Aug 31, 2016 at 6:30 PM, Michael Niedermayer <mich...@niedermayer.cc
> On Mon, Aug 15, 2016 at 10:27:47AM -0700, Sophia Wang wrote:
> > Of the 3 functions that directly add to matroska->packets, 2 of them will
> > always return 0 afterwards, and the third (matroska_parse_rm_audio) will
> > only return something other than 0 in the case of AVERROR(ENOMEM) or
> > AVERROR(EINVAL).
> but they can add multiple packets, so even if they return 0 there
> could be packets in the buffer after one is consumed
> > All 3 functions are called from matroska_parse_block,
> > which immediately returns the result if there is no error.
> did you mean "if there is AN error" ?
> > If an error does
> > occur, then the error code may eventually be returned, or it may be
> > overwritten by the return value of any of the 3 packet-adding functions.
> > matroska_parse_block is called from matroska_parse_cluster and its helper
> > matroska_parse_cluster_incremental, both of which simply return the
> > (though it maybe overwritten by another invocation in
> > matroska_parse_cluster). So in any case, if packets are added, the only
> > sources of failure are ENOMEM and EINVAL, and I'm not sure if it makes
> > sense to write code to work around those.
> you add code in matroska_resync() and its caller to immedeatly
> break out and return failure if the seek fails.
> At this point there can still be packets in the buffers unless i
> miss something, should the error not be returned after the packets
> that where read before the error ?
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> No great genius has ever existed without some touch of madness. --
> ffmpeg-devel mailing list
ffmpeg-devel mailing list