[FFmpeg-devel] [PATCH 1/3] lavf/mov: Always try to parse mfra if file contains moof boxes

[Tomas Härdin]

Hi

This patchset addresses the issues Spotify has been having reading
fragmented MP4 over HTTP. The issue is that mov.c does hundreds of
seeks unless -use_mfra_for is set to something other than auto.
However, defaulting -use_mfra_for to either pts or dts breaks FATE. I'm
not sure what to do there, so this patch always reads mfra if the file
is fragmented, which stops the entire file being parsed when probing.

The attached zip contains a 51M file demonstrating the issue. I have
sent it to Spotify to make sure it triggers the same issue on their
end. The file has been generated with the following command:

./ffmpeg -t 600 -f lavfi -i "sine,volume=0" -acodec pcm_s16le -moov_size 1024 -frag_size 65536 -movflags +faststart -y frags.mp4

Because it is PCM and silent it compresses well, so it won't take up
much bandwidth for fate-rsync. Another option could be to generate it.

"ffprobe -loglevel debug frags.mp4" before and after this patch:
[AVIOContext @ 0x3d90d40] Statistics: 27377155 bytes read, 418 seeks
real    0m0,579s
user    0m0,023s
sys     0m0,106s

[AVIOContext @ 0x4530d40] Statistics: 146951 bytes read, 4 seeks
real    0m0,087s
user    0m0,005s
sys     0m0,024s

/Tomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-lavf-mov-Always-try-to-parse-mfra-if-file-contains-m.patch
Type: text/x-patch
Size: 1075 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20241211/90bd0a12/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: frags.zip
Type: application/zip
Size: 123284 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20241211/90bd0a12/attachment.zip>