[FFmpeg-user] Any way to estimate moov_size in mov/mp4?

[Stefan Oltmanns]

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
> ffmpeg-user at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".