[FFmpeg-devel] EOF and IO error checking

Marton Balint cus at passwd.hu
Thu Aug 22 11:47:17 EEST 2019



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


More information about the ffmpeg-devel mailing list