On Fri, 31 May 2024, Timo Rothenpieler wrote:
On 31/05/2024 10:53, Martin Storsjö wrote:
This allows ending up with a normal, non-fragmented file when
the file is finished, while keeping the file readable if writing
is aborted abruptly at any point. (Normally when writing a
mov/mp4 file, the unfinished file is completely useless unless it
is finished properly.)
This results in a file where the mdat atom contains (and hides)
all the moof atoms that were part of the fragmented file structure
initially.
---
This is, incidentally, how Apple devices do (or at least did, at some
point) their writing of files when recording, at least with some
of their userspace APIs.
---
doc/muxers.texi | 7 +++++
libavformat/movenc.c | 59 ++++++++++++++++++++++++++++++++---
libavformat/movenc.h | 4 ++-
libavformat/version.h | 4 +--
tests/fate/lavf-container.mak | 3 +-
tests/ref/lavf/mov_hide_frag | 3 ++
6 files changed, 71 insertions(+), 9 deletions(-)
create mode 100644 tests/ref/lavf/mov_hide_frag
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 6340c8e54d..e313b5e631 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -569,6 +569,13 @@ experimental, may be renamed or changed, do not use
from scripts.
@item write_gama
write deprecated gama atom
+
+@item hide_fragments
+After writing a fragmented file, convert it to a regular, non-fragmented
+file at the end. This keeps the file readable while it is being
+written, and makes it recoverable if the process of writing the file
+gets aborted uncleanly, while still producing an easily seekable
+and widely compatible non-fragmented file in the end.
@end table
I somehow feel like calling the option like this would not help an
"unsuspecting user" to find it, cause it's not immediately obvious that
it solves the issue it does.
Though I don't immediately have a better idea either. Something like
"safe_recording"? "crash_resilience"?
Can't say I'm a fan of those either.
Yeah, those don't seem better either - and they stray from a somewhat
precise technical definition of what it does, into a vauge guess at what
the user wants.
On that note, from the point of view of setting the option that way, the
option should probably imply fragmentation (and if no fragmentation method
is enabled, e.g. no specific time interval etc, it could default to
fragmenting on keyframes or similar), instead of as right now, when it
requires you to specify fragmentation separately (which requires the user
even more to know what they're doing).
// Martin
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
