ons 2024-12-11 klockan 15:24 +0100 skrev 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.
Oh and this of course also needs a FATE test. I didn't bother writing that yet before I get some feedback. But the idea I have is to check the number of seeks performed and require that it not be more than 4 in this case. I assume we have access to sed on all systems FATE runs on The second file Spotify sent me is more difficult to deal with because it is not fragmented. It just has lots of mdat boxes, the moov box at the end and no mfra. There the idea I have to improve on Spotify's heuristic moov search is to look for it at offsets exponentially back from the end of the file. For example, starting at SEEK_END - 64k, then -128k, -256k and so on up to some cutoff, with 8 bytes overlap to account for the size of the box header. Thoughts on such a solution? Maybe there's a better way? /Tomas _______________________________________________ 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".
