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

Gyan Doshi ffmpeg at gyani.pro
Fri Dec 2 06:11:21 EET 2022



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.

Regards,
Gyan


More information about the ffmpeg-devel mailing list