Re: [FFmpeg-devel] [PATCH] movenc: Add an option for hiding fragments at the end

[Timo Rothenpieler <timo@rothenpieler.org>]

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.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".