Re: [FFmpeg-user] Any way to estimate moov_size in mov/mp4?
On 2/10/2023 2:26 PM, Stefan Oltmanns wrote: 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) In the ffmpeg source it appears to be in libavformat/mov.c and movenc.c, but the info actually included will vary with what's being stuffed into the container. Sidestepping the question, there are decent write-ups at https://atomicparsley.sourceforge.net/mpeg-4files.html https://www.cimarronsystems.com/wp-content/uploads/2017/04/Elements-of-the-H.264-VideoAAC-Audio-MP4-Movie-v2_0.pdf And while it's old, you could grab a copy of AtomicParsley and see what's in various test files. (Please do not top-post on this mailing list, thanks.) z! ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Any way to estimate moov_size in mov/mp4?
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@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Any way to estimate moov_size in mov/mp4?
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@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] Convert Streaming Stereo Audio to Mono?
I am completely new to FFmpeg installed on Debian linux. For reasons irrelevant here, I like to listen to many kinds of music in mono playback. I have discovered how to use ffmpeg to convert stereo files to mono, if I have the files in hand. I subscribe to Tidal which, of course, streams in stereo. Is there a way for ffmpeg to convert the streamed Tidal file to mono in real time? Thank you. Ken Sent with Tutanota Open Source and Secure ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Any way to estimate moov_size in mov/mp4?
> On 10 Feb 2023, at 11:40, Stefan Oltmanns wrote: > > Hello, > > ffmpeg allows to set a reserved space for the moov at the beginning of > the file using the "-moov_size" option. > This will waste some space, but prevent the (in some cases very > time-consuming) second pass of "-movflags faststart" if you want to have > the moov atom at the beginning of the file. > > If the reserved space is too small the moov atom gets written at the end > from my testing (the documentation seems to be wrong here, it states > muxing will fail, or why could the produced mov file still be played?). > > Is there any way to properly estimate the moov size? In my use case it > should be rather simple: PCM audio, DNXHD codec (all-I frames, almost > CBR), known number of frames. > As the produced files are very big anyway I don't mind wasting a few MB > by overestimating. I don’t get it. Faststart is for internet / network playing only, when the entire file is not yet available. 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. Having said that: Checking the size of the moov atom is relative simple, use ‘any’ atom parser, or render the same file for 1 frame with a scale as small as you can get, with highly compressed sound and use the entire file size for the MOOV atom size (plus a bit). Hth, Bouke ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] Any way to estimate moov_size in mov/mp4?
Hello, ffmpeg allows to set a reserved space for the moov at the beginning of the file using the "-moov_size" option. This will waste some space, but prevent the (in some cases very time-consuming) second pass of "-movflags faststart" if you want to have the moov atom at the beginning of the file. If the reserved space is too small the moov atom gets written at the end from my testing (the documentation seems to be wrong here, it states muxing will fail, or why could the produced mov file still be played?). Is there any way to properly estimate the moov size? In my use case it should be rather simple: PCM audio, DNXHD codec (all-I frames, almost CBR), known number of frames. As the produced files are very big anyway I don't mind wasting a few MB by overestimating. Best regards Stefan ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
