[FFmpeg-devel] [PATCH] avformat/matroskadec: retain error codes in matroska_resync() and matroska_read_packet()

[Michael Niedermayer]

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 result
> (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. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160901/ea75b18b/attachment.sig>