[FFmpeg-devel] [PATCH v2 2/2] avformat/mov: re-allow zero sample sizes if that is not the default

Marton Balint cus at passwd.hu
Thu Dec 15 01:07:18 EET 2022



On Mon, 12 Dec 2022, Chris Ribble wrote:

> On Sun, Dec 11, 2022 at 2:34 PM Chris Ribble <chris.ribble at resi.io> wrote:
>>
>> This looks great and I've confirmed it fixes the issue. I see the
>> warning on STDERR about ignoring the trun box: "Ignoring trun box with
>> zero sized samples", which is great.
>>
>
> Actually, this introduces a new issue when I try to transcode the
> problematic mp4 and then segment it with the DASH muxer.
>
> It appears that ignoring the trun box while reading the input affects
> the segment alignment of the audio with the video.The durations jitter
> around quite a bit and some of them are very long. The same problem
> seems to exist whether I transcode or copy the audio.

Well, remuxing sparse audio packets certainly can cause issues. For a full 
transcode, I did not expect that much difference, for the audio gaps you 
should be able to generate silence with -af aresample=async=1 or similar.

Overall, I am not sure what to do here:

1) Simply revert original patch, and make it work same as before, and
    accept that 0-sized packets can be generated by the MOV demuxer, or
    fuzzed files can cause practically infinite loops (not that unusual for
    multimedia formats)

2) Apply this patchset which makes the MOV demuxer ignore the 0-sized
    packets and fixes the original fuzzing issue, but causing some strange
    issues when remuxing or transcoding because the audio packets become
    sparse.

3) Dig deeper what goes wrong with remuxing/reencoding with sparse audio.
    Unfortunately I won't have time to do this.

Comments are welcome.

Thanks,
Marton



More information about the ffmpeg-devel mailing list