> And 'moov' contains the info needed to make sense of the rest of the file. > Now that it has that, it goes back and downloads from where it > short-circuited before. At <10MBs, as you say, it might make more sense to > download the whole file and then work with it on disk. But for larger > downloads, or with a not-so-great connection, I'd imagine opening/closing > multiple connections isn't as big a cost, resource or performance wise. And > maybe more so in situations like where one might not need the video stream, > for example.
> -multiple_requests is supposed to keep the same connection, but I don't know > if it actually works, especially depending on which ssl. If it doesn't, you > can always curl or wget the whole file and avoid the extra connections' > overhead, probably? Assuming that the media is self-contained in that one > file, that is. > Regards, > Ted Park Thanks Ted, this confirm my suspicion. Grabbing the whole file is probably not going to help much as even with a relatively small file of several Mb it will probably take about the same time initially to download it as will multiple connections that read small number of bytes. As you suspected -multiple_requests doesn't seem to help to speed things up despite the keep-alives. Fortunately this appears to be a corner case and usually ffmpeg can get going after a single connection, this likely depends on how the video file was created. Cheers, Vlad _______________________________________________ ffmpeg-user mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
