On Sun, 18 Aug 2019, Michael Niedermayer wrote:

On Sat, Aug 17, 2019 at 09:10:59PM +0200, Marton Balint wrote:
Hi,

As you might now avio_feof() returns true both in case of actual EOF and in
case of IO errors.

Some demuxers (matroska) have special handling for this exact reason, e.g.:

if (avio_feof(pb)) {
    if (pb->error) {
        return pb->error;
    } else {
        return AVERROR_EOF;
    }
}

Most of the demuxers do not, so there is a real chance that IO errrors are
mistaken for EOF.

What should we do about this?

a) Fix every demuxer to return IO error if there is one.

b) Add special code to ff_read_packet which checks if there is an error in
the IO context and return that if there is?


c) Add code to ffmpeg.c which checks the IO context error code after every
av_read_frame call?

This while generally correct is not guranteed to be correct.
The internal IO context may have an IO error without the demuxer having an
error. From the possibility of reconnects to redundancy to errors after
all essential parts of a file ...
so this may need some flag per demuxer that either declares this relation
true or a flag declaring it false

Do you have an example in mind for a demuxer which specifically needs this? From the top of my head I can't think of one.

Reconnects happen in the protocol handlers, so errors there should not affect the AVIO context errors.

I am also sceptical about the use case of gracefully handling IO errors in non-essential parts of the file. Signalling IO errors is a lot more important and I bet there are cases where some demuxer won't set the packet corrupt flag (which is by the way not propagated correctly through the API) if it encounters an IO error when reading something.

In any case, I don't mind too much option a), if that what seems more clean but we will probably miss a few cases of the issue.

Thanks,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Reply via email to