My intention for having the moov atom at the beginning:
a) in case the file gets truncated for some reason, it is still
playable, you may loose some parts of your footage but not all (I know
there is a tool that should possibly be able to restore the moov atom if
you have a similar file, but for me it always crashes)
b) A well-known video platform can start processing the file before it
is fully uploaded, but of course not if the moov atom is at the end
c) If the files are stored on a slow external HDD or a NAS, there can be
a few seconds before video starts playing like mentioned by Carl (if you
have dozens of files and quickly what to find the right one that can be
annoying)
The proposed method is a bit random, but I'll give it a try. Can someone
simply explain what exactly is stored in the moov atom (not in theory
what everything could be in there, but what ffmpeg actually writes there
like "video codec information: x byte, audio codec information: x byte,
timecode+byteoffset: x byte for each frame and so on)
Best regards
Stefan
Am 10.02.23 um 21:40 schrieb Carl Zwanzig:
On 2/10/2023 3:20 AM, Bouke / Videotoolshed wrote:
Faststart is for internet / network playing only, when the entire file
is not yet available.
Not only for network playback; maybe often used for that but there's no
reason to limit the use.
If movflags faststart is needed, it should be darn fast as your files
’should’ be fairly small, as they are intended for (relative) low
bandwith. > There is NO penalty for having the MOOV atom at the end if
a file is
local, as parsing all atoms will not take longer than a few secs if the
file is local.
It's difficult to characterize a 2 hour FHD (or 4k) video file as small
or intended for low bandwidth, and there -is- a penalty ("a few
seconds"). Many playout servers will play from MP4 files and "a few
seconds" is a few too long when a specific file is to play. Some
software will pre-open the file and start it on time, but that's no
reason to not put the necessary info at the head of the file. (The OP
also says "As the produced files are very big anyway I don't mind
wasting a few MB by overestimating.")
It would be interesting to see how accurate Bouke's technique is for
estimating the moov atom size; probably close enough but confirmation is
always good.
Later,
z!
_______________________________________________
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".
_______________________________________________
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".
