[FFmpeg-devel] [PATCH 3/3 v2] avformat/movenc: set delay_moov flag when writing DASH

[James Almer]

On 11/22/2024 10:04 AM, Martin Storsjö wrote:
> On Fri, 22 Nov 2024, James Almer wrote:
> 
>> On 11/22/2024 5:32 AM, Martin Storsjö wrote:
>>> On Thu, 21 Nov 2024, James Almer wrote:
>>>
>>> I'm a little reluctant to do this; IIRC the delay_moov flag 
>>> significantly changes the sequence of what boxes gets output at what 
>>> time, which affects things for API users integrating this into 
>>> segmentation setups. (I presume that's why you changed the movenc 
>>> test case as well?)
>>
>> The changes in md5 hashes there are only the missing dash brand in the 
>> output, afaict. I removed the dash flag (which is not what the test 
>> was about anyway) to make sure delay_moov was not included in the test 
>> that only wanted empty_moov.
> 
> Ah, I see.
> 
>>> That's why I'd like to keep delay_moov an explicit opt-in - even if 
>>> it kinda is necessary to get the timing entirely correct. Users that 
>>> don't need it, and rely on getting the whole moov during 
>>> avformat_write_header, would be broken by this change.
>>
>> But who uses the mov muxer with the dash movflag on its own instead of 
>> through the dash muxer, which explicitly enables delay_moov? afaik 
>> that flag only ensures the brand is added.
>> Functionality wise it does nothing more than select other flags. Or 
>> rather, it should only do that, right? And if it does not, whatever 
>> code looks for it should be changed to look for the fragment flag 
>> instead.
> 
> I would expect that many users use it, as an umbrella option for "modern 
> fragmented mp4 with all the flavours you need for segmented use". A more 
> modern similar umbrella flag would probably be "cmaf" though, but that 
> flag was added (much) later.
> 
> Yes, it's also possible to explicitly request 
> "empty_moov+default_base_moof", but it's not possible to directly set 
> the flag corresponding to FF_MOV_FLAG_FRAGMENT (which is "make sure 
> we're fragmenting; if the user didn't specify an option for 
> fragmentation, pick a default one"). But just picking cmaf or dash as 
> umbrella option for these setups is convenient.
> 
> 
> Any project doing segmented mp4, by segmenting externally (rather than 
> using our muxers), can likely be using this flag - I use it myself in 
> this fashion in $dayjob code. Yes I can obviously change that now that 
> I'm aware of this change, but I would believe that there are a number of 
> other users using it in a similar way - Hyrum's Law etc.
> 
> And while we do have our segmenting muxers (dashenc etc), I would expect 
> that many of the advanced use cases do the segmenting themselves.
> 
> I.e., I was the one to add the dash flag back in the day, and I would be 
> surprised by this change, if I hadn't caught it in review.
> 
> And if the prime use case in mind is the dash muxer, I don't see why the 
> dash muxer can't keep on passing the delay_moov flag separately?

It still does, but back to what you said, users of the mov muxer that 
use the dash flag as a framented output umbrella will not get correct 
timings just with it.

In any case, I'll drop this patch. People can just use +dash+delay_moov.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20241122/be976767/attachment.sig>