ons 2024-10-30 klockan 11:44 +0100 skrev Tomas Härdin:
> I also made some test files to demonstrate the differences in behavior.
> What's being addressed here is early termination of the file. One thing
> to bikeshed over is whether to return AVERROR_EOF or
> AVERROR_INVALIDDATA in that case. The attached files demonstrate a
> change in return value depending on how short a flac file is. It might
> make more sense to always return AVERROR_EOF since being truncated is
> fundamentally the issue with the file in these cases

Actually I feel like bikeshedding/philosophizing over this a bit since
it is probably relevant to other parts of the code. I feel there is an
important qualitative difference between a file being too short and a
file containing bad data, and we'd like to within the best of our
abilities tell the user what the problem is. But this isn't always so
easy.

Consider a length field followed by not enough data. This could happen
for two reasons: either the file was terminated early or the length
field was written incorrectly or somehow corrupted. Should we assume
that the file was written correctly and cut short, or the opposite?

In this specific case I think the answer is easy: always return EOF.
Why? Because the streaminfo chunk is 34 bytes by definition, and unless
the muxer is incredibly broken, an incomplete read is almost certainly
due to the file being cut early

We could in principle move the checks for metadata_size further up, but
it's probably not worthwhile here. In a proper parsing framework this
kind of stuff could be expressed in a grammar. For streaminfo it should
match \x00\x00\x00\x22 exactly

TL;DR: I'm going to change to returning EOF here, unless someone
objects

/Tomas
_______________________________________________
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