3 ms·
> that means the entire file must be read/scanned to get to the metadata when the browser requests it which means a long delay depending on the size of the file
by oefrha 1y ago
> that means the entire file must be read/scanned to get to the metadata when the browser requests it which means a long delay depending on the size of the file.
Not really, unless your server doesn’t support range requests, browsers are smart enough to request the end of the file where a non-faststart moov atom typically lives. But yes, you should use faststart.
You’re right that this appears to be the work of someone who’s not very adept at ffmpeg. Which shouldn’t be surprising; as a power user, maybe even expert at ffmpeg, unless I need to write a complex filter graph, consulting an LLM will just slow me down—people like me have no need for this.
- dylan604 1y ago> Not really, unless That's great if you built the server and know this. If you are just providing files for someone to use in a location you know nothing about, best practices for web-friendly is to have the MooV at the head of the file. Placing it at the end is just asking for trouble. Anyone that's been there done that and experienced MooV at the end one time will always move it to the head from then on. An LLM should know this. Someone training an LLM should know this. Making a tool like this that does not do best practices is just a bad tool. Arguing against best practices verges on making one a tool themself. Don't be a tool