> More strict enforcement of sample size was introduced to avoid DOS/Timeout > with crafted (fuzzed) files and disallow emitting zero sized packets. > > Invalid file support is not something that is always worth doing, there > are other, more important factors, like limiting code complexity or > improving resiliance against denial of service. The problem here is that I > honestly don't know if a zero sample size is against spec, just stupid, or > there is a legitimate use for it. > > So I sent a 2 patch series which fixes the original issue differently. > Please test and review them if you can.
Marton, Thank you for looking into this further. I tried your patch series and FFmpeg still generates an error (AVERROR_INVALIDDATA) while processing the moof fragment with zero-sized samples. It seems like !(flags & MOV_TRUN_SAMPLE_SIZE) evaluates to true when the flag is set (512 is "inverted" to 1). Is that what you had in mind? If I change it to this, things work as expected for my input mp4: if (entries && !frag->size && (flags & MOV_TRUN_SAMPLE_SIZE != MOV_TRUN_SAMPLE_SIZE)) return AVERROR_INVALIDDATA; Sorry if I was supposed to provide this feedback on the patch series itself; I'm happy to do so there as needed. Thanks, Chris _______________________________________________ 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".
