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

[Martin Storsjö]

On Mon, 17 Jun 2024, Gyan Doshi via ffmpeg-devel wrote:

> On 2024-06-17 04:08 pm, Martin Storsjö wrote:
>> On Sat, 15 Jun 2024, Gyan Doshi wrote:
>>
>>> On 2024-06-15 03:54 am, Dennis Sädtler via ffmpeg-devel wrote:
>>>> On 2024-06-14 13:23, Gyan Doshi wrote:
>>>>>
>>>>> On 2024-06-14 04:35 pm, Timo Rothenpieler wrote:
>>>>>> On 14/06/2024 12:44, Martin Storsjö wrote:
>>>>>>> On Fri, 14 Jun 2024, Gyan Doshi wrote:
>>>>>>>
>>>>>>>> On 2024-06-14 02:18 am, Martin Storsjö wrote:
>>>>>>>>> On Thu, 13 Jun 2024, Gyan Doshi wrote:
>>>>>>>>>
>>>>>>>>>> On 2024-06-13 06:20 pm, Martin Storsjö wrote:
>>>>>>>>>>>
>>>>>>>>>>> I'd otherwise want to push this, but I'm not entirely 
>>>>>>>>>>> satisfied with the option name quite yet. I'm pondering if we 
>>>>>>>>>>> should call it "hybrid_fragmented" - any opinions, Dennis or 
>>>>>>>>>>> Timo?
>>>>>>>>>>
>>>>>>>>>> How about `resilient_mode` or `recoverable`?
>>>>>>>>>> I agree that the how is secondary.
>>>>>>>>>
>>>>>>>>> Those are good suggestions as well - but I think I prefer 
>>>>>>>>> "hybrid_fragmented" still.
>>>>>>>>>
>>>>>>>>> In theory, I guess one could implement resilient writing in a 
>>>>>>>>> number of different ways, whereas the hybrid 
>>>>>>>>> fragmented/non-fragmented only is one.
>>>>>>>>>
>>>>>>>>> So with a couple other voices agreeing with the name 
>>>>>>>>> "hybrid_fragmented", I'll post a new patch with the option in 
>>>>>>>>> that form - hopefully you don't object to it.
>>>>>>>>
>>>>>>>> The term hybrid is not applicable here. The fragmented state is 
>>>>>>>> transient during writing and contingent in the finished artifact 
>>>>>>>> depending on how the writing process concluded.
>>>>>>>> Hybrid implies both modes available e.g.. a hybrid vehicle can 
>>>>>>>> use both types of energy sources. The artifact here will be one 
>>>>>>>> _or_ the other.
>>>>>>>
>>>>>>> Sure, the file itself is either or, but the process of writing 
>>>>>>> will have utilized both. TBH, I don't see it as such a 
>>>>>>> black-or-white thing.
>>>>>>>
>>>>>>> What do the others who have chimed in on the thread think, 
>>>>>>> compared to calling it "recoverable" or "resilient_mode"?
>>>>>>
>>>>>> I don't have a super strong opinion on it, but out of the options 
>>>>>> provided, I'd prefer the hybrid_ one, since there's a good chance 
>>>>>> it'll become an established term now that OBS presents it quite 
>>>>>> publicly visible.
>>>>>
>>>>> The OBS dev intends to change the term:
>>>>>
>>>>> "Come up with a better name than "Hybrid MP4" that hopefully won't 
>>>>> confuse users"
>>>>>
>>> 
> https://github.com/obsproject/obs-studio/pull/10608#issuecomment-2095222024 
>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>> Gyan
>>>>
>>>> Now that it's merged and in the hands of users I don't have any 
>>>> intention of changing the name any more.
>>>> We had some chats about about it, but nobody suggested anything that 
>>>> people agreed was better, so it stuck.
>>>>
>>>> While "resilient" certainly fits, it could equally apply to regular 
>>>> fragmented MP4 (e.g. vMix uses that terminology for fMP4 if I'm not 
>>>> mistaken).
>>>> The important attribute with this approach is that it's resilient 
>>>> *and* compatible, and I'm still not sure how to get that across in 
>>>> name alone.
>>>
>>> How about `failsafe`?
>>
>> I don't see how that differs from "resilient", as a regular fragmented 
>> file also is failsafe (or resilient) in the same way - while the 
>> special thing here is that it's both fragmented and not.
>
> The expert user already knows to save a fragmented file if they want 
> resilience. This option saves them a remux step if the original writing 
> ends gracefully.
> For all other users,  the value proposition _is_ the resilience.  If the 
> muxing ends normally, they just have a normal file. If it ends 
> prematurely, they just want to be able to convert to a regular seekable 
> MP4. The fact that it is saved in fragmented or any other mode is 
> irrelevant - an academic detail at best.

Sure

> Ultimately, as long as the doc is clear about what the use of this 
> option is, and what to do next if the muxing does abort, it should not 
> matter too much what the option is called.

So, are you saying you'd accept the hybrid_fragmented name, as long as the 
docs explain this correctly?

> But just like the faststart flag name identifies the purpose instead of 
> being called something like moov_in_front, hopefully so will the name 
> here.

TBH, the "faststart" name isn't necessarily the best either - although 
it's clearly better than moov_in_front though. But here, the name 
"faststart" was already established for the concept of this kind of 
operation, from the "qt-faststart" tool before it was integrated into the 
muxer.

And here, we seem to begin to have some sort of similar establishing of 
"hybrid" as name for this kind of operation.

But if this really is inacceptable to you, I guess all others who support 
that name, will have to figure out which of the alternate names we prefer.

// Martin