[FFmpeg-devel] [PATCH] Revert "avformat/mov: disallow a zero sample size in trun atoms"

[Marton Balint]

On Fri, 2 Dec 2022, Gyan Doshi wrote:

>
>
> On 2022-12-02 06:16 am, Chris Ribble wrote:
>>  On Thu, Dec 1, 2022 at 4:51 PM Marton Balint <cus at passwd.hu> wrote:
>>>  Can you explain why those files are considered valid, or why it makes
>>>  sense to generate such files?
>>>
>>>  Thanks,
>>>  Marton
>>>
>>  As far as I can tell, the file that a user provided with this problem
>>  was generated by an encoder (running FFmpeg 3.4) that started writing
>>  zero-sized samples when their video switcher + capture card stopped
>>  receiving audio input. I'm not arguing that it's good for files to be
>>  generated like this, but it's nice for FFmpeg to be able to process
>>  them all the same (i.e. the robustness principle).
>>
>>  With this patch reverted, FFmpeg can accept an input file that is
>>  partially broken (with playback anomalies due to the presence of
>>  zero-sized samples) and produce a valid, working output mp4 (or DASH
>>  stream), just like it could in release 5.0 and older.
>>
>>  One of the best things about FFmpeg is that it can fix invalid
>>  container metadata. I feel like losing that capability for this
>>  scenario is a regression.
>
> FWIW, we don't discard regular MP4s with sample entries of 0 in stts, which 
> is only permitted for the last solo sample in a track. So, I agree.

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.

Thanks,
Marton