From: "Dennis Sädtler via ffmpeg-devel" <ffmpeg-devel@ffmpeg.org>
To: ffmpeg-devel@ffmpeg.org
Cc: "Dennis Sädtler" <dennis@obsproject.com>
Subject: Re: [FFmpeg-devel] [PATCH v2] movenc: Add an option for hiding fragments at the end
Date: Sat, 15 Jun 2024 00:24:34 +0200
Message-ID: <e95d2a0c-eb25-2991-afe5-bdf271d0a403@obsproject.com> (raw)
In-Reply-To: <b2f11180-70b5-49cc-8389-e4a09c812949@gyani.pro>
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.
Obviously FFmpeg has a different target demographic and can use
something different than OBS, "Hybrid MP4" is just what I came up with
as user-facing name for the feature at the time.
~Dennis
_______________________________________________
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 22:24 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
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 [this message]
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=e95d2a0c-eb25-2991-afe5-bdf271d0a403@obsproject.com \
--to=ffmpeg-devel@ffmpeg.org \
--cc=dennis@obsproject.com \
/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