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

[Martin Storsjö]

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
>> +
>> + at 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