From: Gyan Doshi <ffmpeg@gyani.pro>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH v2] movenc: Add an option for hiding fragments at the end
Date: Fri, 14 Jun 2024 09:57:07 +0530
Message-ID: <59061f5d-cc2c-4cf4-8259-ec05f5660002@gyani.pro> (raw)
In-Reply-To: <ac4eda92-3350-d0dc-2220-55c8dfee1890@martin.st>
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:
>>> On Wed, 5 Jun 2024, 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.
>>>> ---
>>>> v2: Made the flag implicitly set FF_MOV_FLAG_FRAGMENT (as it makes
>>>> no sense without it).
>>>>
>>>> Updated the description of the flag to "Write a fragmented file that
>>>> is converted to non-fragmented at the end".
>>>>
>>>> Kept the flag named "hide_fragments", but I'm also pondering if we
>>>> maybe should go for a name like "hybrid_fragmented" or so, as a
>>>> better description of _what_ it produces, as opposed to _how_ it
>>>> does things. (One could also consider "hybrid_mp4", but even if mp4
>>>> is the main thing, the same also goes for mov and a bunch of other
>>>> related formats.)
>>>
>>> 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.
Regards,
Gyan
_______________________________________________
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".
next prev parent reply other threads:[~2024-06-14 4:27 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-05 11:47 Martin Storsjö
2024-06-13 12:50 ` Martin Storsjö
2024-06-13 13:44 ` Timo Rothenpieler
2024-06-13 13:45 ` Gyan Doshi
2024-06-13 20:48 ` Martin Storsjö
2024-06-14 4:27 ` Gyan Doshi [this message]
2024-06-14 10:44 ` Martin Storsjö
2024-06-14 11:05 ` Timo Rothenpieler
2024-06-14 11:08 ` Martin Storsjö
2024-06-14 11:23 ` Gyan Doshi
2024-06-14 22:24 ` Dennis Sädtler via ffmpeg-devel
2024-06-15 9:15 ` Gyan Doshi
2024-06-17 10:38 ` Martin Storsjö
2024-06-17 12:41 ` Gyan Doshi via ffmpeg-devel
2024-06-19 12:34 ` Martin Storsjö
2024-06-19 12:38 ` Gyan Doshi
2024-06-13 19:41 ` Dennis Sädtler via ffmpeg-devel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=59061f5d-cc2c-4cf4-8259-ec05f5660002@gyani.pro \
--to=ffmpeg@gyani.pro \
--cc=ffmpeg-devel@ffmpeg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git