Re: [FFmpeg-devel] A change in r_frame_rate values after upgrade to FFmpeg 6.1

[Kieran Kunhya via ffmpeg-devel]

On Mon, Sep 23, 2024 at 8:56 PM Anton Khirnov  wrote:
>
> Quoting Kieran Kunhya via ffmpeg-devel (2024-09-23 21:30:09)
> > > On Mon, Sep 23, 2024 at 4:45 PM Kieran Kunhya via ffmpeg-devel 
> > >  wrote:
> > >>
> > >> On Mon, Sep 23, 2024 at 3:27 PM Anton Khirnov  wrote:
> > >> >
> > >> > Quoting Antoni Bizoń (2024-09-23 10:09:51)
> > >> > > I understand that the r_frame_rate is the lowest framerate with which
> > >> > > all timestamps can be represented accurately. And I know it is just a
> > >> > > guess. But why did the logic behind the calculation change?
> > >> >
> > >> > Because you're most likely using a codec like H.264 or MPEG-2 that
> > >> > allows individually coded fields. In that case the timebase must be
> > >> > accurate enough to represent the field rate (i.e. double the frame
> > >> > rate), but the code doing this was previously unreliable, so you'd
> > >> > sometimes get r_frame_rate equal to the frame rate rather than field
> > >> > rate. That is not the case anymore.
> > >>
> > >> This is bizarre and kafkaesque to say the least.
> > >
> > >
> > > Should we schedule deprecation for one of the two fields? I agree it's 
> > > confusing for end users to check in two fields.
> >
> > avg_frame_rate implies it's not precise in some way.
>
> You might have heard of certain cases where inter-frame intervals are
> not constant, then there is no precisely defined frame rate. When the
> stream is CFR, avg_frame_rate should be precise.

Let's look at the first result for avg_frame_rate where people are
taking the name to be something else:
https://github.com/eugeneware/ffprobe/issues/7

The OP wants a framerate, yet the API takes them down a massive rabbit
hole of voodoo to serve edge cases.
Do you really want edge cases to be treated as first class citizens to
the detriment of the majority?

There are CFR streams, there are flags to say things are CFR.

Regards,
Kieran Kunhya
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] A change in r_frame_rate values after upgrade to FFmpeg 6.1

[Kieran Kunhya via ffmpeg-devel]

> On Mon, Sep 23, 2024 at 4:45 PM Kieran Kunhya via ffmpeg-devel 
>  wrote:
>>
>> On Mon, Sep 23, 2024 at 3:27 PM Anton Khirnov  wrote:
>> >
>> > Quoting Antoni Bizoń (2024-09-23 10:09:51)
>> > > I understand that the r_frame_rate is the lowest framerate with which
>> > > all timestamps can be represented accurately. And I know it is just a
>> > > guess. But why did the logic behind the calculation change?
>> >
>> > Because you're most likely using a codec like H.264 or MPEG-2 that
>> > allows individually coded fields. In that case the timebase must be
>> > accurate enough to represent the field rate (i.e. double the frame
>> > rate), but the code doing this was previously unreliable, so you'd
>> > sometimes get r_frame_rate equal to the frame rate rather than field
>> > rate. That is not the case anymore.
>>
>> This is bizarre and kafkaesque to say the least.
>
>
> Should we schedule deprecation for one of the two fields? I agree it's 
> confusing for end users to check in two fields.

avg_frame_rate implies it's not precise in some way. I think the OP is
correct here that the behaviour makes no sense.
If something says frame_rate it's the rate of frames, not the rate of
fields or anything else.

Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] A change in r_frame_rate values after upgrade to FFmpeg 6.1

[Kieran Kunhya via ffmpeg-devel]

On Mon, Sep 23, 2024 at 3:27 PM Anton Khirnov  wrote:
>
> Quoting Antoni Bizoń (2024-09-23 10:09:51)
> > I understand that the r_frame_rate is the lowest framerate with which
> > all timestamps can be represented accurately. And I know it is just a
> > guess. But why did the logic behind the calculation change?
>
> Because you're most likely using a codec like H.264 or MPEG-2 that
> allows individually coded fields. In that case the timebase must be
> accurate enough to represent the field rate (i.e. double the frame
> rate), but the code doing this was previously unreliable, so you'd
> sometimes get r_frame_rate equal to the frame rate rather than field
> rate. That is not the case anymore.

This is bizarre and kafkaesque to say the least.

Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH, v2] avcodec/amfenc: increase precision of Sleep() on Windows

[Kieran Kunhya via ffmpeg-devel]

On Mon, Aug 19, 2024 at 7:31 PM Timo Rothenpieler  wrote:
>
> On 19.08.2024 16:23, Araz Iusubov wrote:
> > From: Evgeny Pavlov 
> >
> > This commit increase precision of Sleep() function on Windows.
> > This fix reduces the sleep time on Windows to improve AMF encoding
> > performance on low resolution input videos.
> >
> > Fix for issue #10622
> >
> > We evaluated CreateWaitableTimerExW with
> > CREATE_WAITABLE_TIMER_HIGH_RESOLUTION flag. In fact, this function has
> > the same precision level as the Sleep() function.
> >
> > Usually changing the time resolution will only affect the current
> > process and will not impact other processes, thus it will not cause a
> > global effect on the current system. Here is an info from
> > documentation on timeBeginPeriod
> > https://learn.microsoft.com/en-us/windows/win32/api/timeapi/nf-timeapi-timebeginperiod
> >
> > "Prior to Windows 10, version 2004, this function affects a global
> > Windows setting. For all processes Windows uses the lowest value (that
> > is, highest resolution) requested by any process. Starting with
> > Windows 10, version 2004, this function no longer affects global timer
> > resolution. For processes which call this function, Windows uses the
> > lowest value (that is, highest resolution) requested by any process.
> > For processes which have not called this function, Windows does not
> > guarantee a higher resolution than the default system resolution."
>
> Even modifying the current process is not acceptable, since lavc is
> frequently embedded in other applications, which might not expect
> this/be aversely impacted by it.
>
> Why does the AMF wrapper need to sleep at all?

Agreed, we can't have things like this in FFmpeg. This might be
acceptable in a binary blob but not in an open source project.

Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] avcodec/h264dec: Remove ff_h264_draw_horiz_band

[Kieran Kunhya via ffmpeg-devel]

On Fri, Jun 14, 2024 at 1:53 PM Paul B Mahol  wrote:
>
>
>
> On Fri, Jun 14, 2024 at 2:41 PM Kieran Kunhya via ffmpeg-devel 
>  wrote:
>>
>> On Sun, Jun 9, 2024 at 2:39 AM Andreas Rheinhardt
>>  wrote:
>> >
>> > The H.264 decoder does not support draw_horiz_band (it does not have
>> > the AV_CODEC_CAP_DRAW_HORIZ_BAND), making ff_h264_draw_horiz_band()
>> > legally dead. The function here always calls draw_horiz_band
>> > in coded order, although the default case is display order.
>>
>> Why would you want a low latency decode mode with reordering?
>> I have no idea about hwaccel, but I believe with low latency encoded
>> video this does work.
>
>
> Since when?
>
> See 0da71265d84b587c7159cd82708ca60ad050dd4c from 2003.
>
> flag remain commented out from then to this day.

It still worked if you controlled the input.

Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] avcodec/h264dec: Remove ff_h264_draw_horiz_band

[Kieran Kunhya via ffmpeg-devel]

On Sun, Jun 9, 2024 at 2:39 AM Andreas Rheinhardt
 wrote:
>
> The H.264 decoder does not support draw_horiz_band (it does not have
> the AV_CODEC_CAP_DRAW_HORIZ_BAND), making ff_h264_draw_horiz_band()
> legally dead. The function here always calls draw_horiz_band
> in coded order, although the default case is display order.

Why would you want a low latency decode mode with reordering?
I have no idea about hwaccel, but I believe with low latency encoded
video this does work.

Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [EXT] Re: Query from Reuters on XZ, open source, and Microsoft

[Kieran Kunhya via ffmpeg-devel]

Hi Raphael,

Answers in my own personal capacity, not the views of my employer, nor the
views of anyone else in FFmpeg.

On Wed, Apr 3, 2024 at 8:26 PM Satter, Raphael (Reuters) <
raphael.sat...@thomsonreuters.com> wrote:

> Dear Kieran & co.,
>
>
>
> Thank you I’ve had a chance to see the talk. It’s a marker of how
> invisible even critical open source projects can be that I wasn’t aware of
> FFmpeg’s role in powering the likes of YouTube and Netflix.
>
>
>
> A few questions I had:
>
>
>
>- How much did Microsoft end up paying for the one-time fix?
>
>
Microsoft did not pay for any fix. There was no actual fix, a command line
option had changed between FFmpeg versions and a volunteer on our bug
tracker pointed this out.

A company which has several FFmpeg developers on its payroll asked
Microsoft (a separate team in private) for a support contract in light of
the fact FFmpeg is used in critical Microsoft products. Instead of
proposing a support contract, Microsoft said a few thousand dollars was
potentially available. This amount is too small to support any developer or
maintenance.


>- What’s the solution here? Your talk mentioned paying developers,
>getting an SLA, or hiring them as consultants … but why would companies
>bother when they can just free ride? I asked the same question to CISA’s
>Jack Cable when he told me that  companies need to “contribute back and
>help build the sustainable open source ecosystem that we get so much value
>from.” Sure, they “need” to do it, but who will punish them if they don’t?
>
>
The Linux Kernel has full time developers hired by big corporations to work
solely on the Linux kernel and to maintain sections of it. However, one can
argue Linux is the exception in open source that proves the rule that
corporations will be free riders.


>- Any other thoughts you might have on this episode – or others you
>think I should speak to – would be greatly appreciated.
>
>
The Demuxed video covers the rest of my thoughts. Microsoft are not the
only company with this attitude.

Regards,
Kieran Kunhya


>
>-
>
> Raphael
>
>
>
> *From:* Kieran Kunhya 
> *Sent:* Wednesday, April 3, 2024 12:39 PM
> *To:* FFmpeg development discussions and patches 
> *Cc:* Satter, Raphael (Reuters) 
> *Subject:* [EXT] Re: [FFmpeg-devel] Query from Reuters on XZ, open
> source, and Microsoft
>
>
>
> *External Email:* Use caution with links and attachments.
>
>
>
> Hi Raphael,
>
>
>
> I was the author of the tweet and I gave a short talk about this topic at
> Demuxed at a video conference last year:
> https://m.youtube.com/watch?v=OIyOEuQQsCQ&t=930s
> 
>
>
>
> That said this is a community project and it would be best to continue the
> discussion on this mailing list unless agreed otherwise.
>
>
>
> Regards,
>
> Kieran Kunhya
>
>
>
> On Wed, 3 Apr 2024, 16:52 Satter, Raphael (Reuters) via ffmpeg-devel, <
> ffmpeg-devel@ffmpeg.org> wrote:
>
> Dear FFMPEG community,
>
> This is Raphael Satter, a journalist with Reuters. I saw your thread on X
> about your experience with Microsoft in the context of the XZ story and
> would love to follow up with a few questions.
>
> Is there a good person to talk to? I’m reachable using the details below
> or on Signal/WhatsApp at +1 202 430 9389.
>
> Raphael
>
> 💻 raphael.sat...@tr.com
> 🌎 raphaelsatter.com
> 
> 📰 reuters.com/authors/raphael-satter
>
> Thomson Reuters
> 1333 H Street NW
> Washington, DC 20005
>
> ☎️ +1 202 843-6302
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Query from Reuters on XZ, open source, and Microsoft

[Kieran Kunhya via ffmpeg-devel]

Hi Raphael,

I was the author of the tweet and I gave a short talk about this topic at
Demuxed at a video conference last year:
https://m.youtube.com/watch?v=OIyOEuQQsCQ&t=930s

That said this is a community project and it would be best to continue the
discussion on this mailing list unless agreed otherwise.

Regards,
Kieran Kunhya

On Wed, 3 Apr 2024, 16:52 Satter, Raphael (Reuters) via ffmpeg-devel, <
ffmpeg-devel@ffmpeg.org> wrote:

> Dear FFMPEG community,
>
> This is Raphael Satter, a journalist with Reuters. I saw your thread on X
> about your experience with Microsoft in the context of the XZ story and
> would love to follow up with a few questions.
>
> Is there a good person to talk to? I’m reachable using the details below
> or on Signal/WhatsApp at +1 202 430 9389.
>
> Raphael
>
> 💻 raphael.sat...@tr.com
> 🌎 raphaelsatter.com
> 📰 reuters.com/authors/raphael-satter
>
> Thomson Reuters
> 1333 H Street NW
> Washington, DC 20005
>
> ☎️ +1 202 843-6302
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] FFmpeg at NAB 2024

[Kieran Kunhya via ffmpeg-devel]

On Sun, Nov 19, 2023 at 9:46 PM Michael Niedermayer
 wrote:
>
> On Sun, Nov 19, 2023 at 02:26:22PM +, Kieran Kunhya via ffmpeg-devel 
> wrote:
> [...]
> > I would not find it acceptable for SPI to pay these costs. I do not feel
> > donors would want their money spent on a corporate show in Las Vegas.
>
> all SPI refunds must be posted to the mailing list and approved by the
> FFmpeg community.
> I have 0 clue if anything like this will be posted by anyone. But if its
> not, there is no way SPI can pay it and if it is then everyone has an
> oppertunity to object.
> If theres no consensus to fund something then stefano and me will not
> approve it. And SPI will not pay it.
>
> So if a few people are against it and they state that publically in
> the corresponding REFUND thread then there is NO way SPI can pay it
>
> I cannot comment on anything else

To be clear I have no issue with reimbursements for small booths at
SCALE, LinuxTAG, FOSDEM etc.
But NAB is a big corporate show with very large costs for graphics,
furniture, union builders etc (put a number in your head and add two
zeroes to the end) and I don't feel donors would want their money
spent on this.

Regards,
Kieran Kunhya
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] FFmpeg at NAB 2024

[Kieran Kunhya via ffmpeg-devel]

On Sun, 19 Nov 2023, 14:05 Derek Buitenhuis, 
wrote:

> Hi,
>
> Followup question...
>
> On 11/1/2023 9:25 PM, Derek Buitenhuis wrote:
> > This is certainly interesting considering we just had a giant thread
> about not using
> > or using SPI, with multiple people accused of having corporate interests.
>
> I noticed FFmpeg is on the NAB floor plan.
>
> This implies FFmpeg has signed a contract with NAB, as to my knowledge,
> you are
> not on the floor plan without doing that.
>
> There is one slight problem here... FFmpeg does not have a legal entity in
> which
> such a contract could have been signed.
>
> So who signed? The "anonymous" corproate entity, on behalf of FFmpeg, with
> out
> our consent?
>
> Pardon my French, but this is sketchy as all fuck.
>

In addition, the remaining costs of the booth, which in my experience total
around twice as much as the floor space itself need to be paid by this
corporate contributor.

I would not find it acceptable for SPI to pay these costs. I do not feel
donors would want their money spent on a corporate show in Las Vegas.

Also no plan has been provided about who will actually be present on the
booth.

Ragards,
Kieran Kunhya

>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA

[Kieran Kunhya via ffmpeg-devel]

On Sat, Nov 11, 2023 at 11:45 PM Michael Niedermayer
 wrote:
>
> On Fri, Nov 10, 2023 at 12:39:45PM +, Kieran Kunhya via ffmpeg-devel 
> wrote:
> > > The list does not match your list, for example Gautam is on your list
> > > but not on joshs
> > >
> > > So my question is still standing, can you explain how your list was 
> > > created?
> > > or where its from?
> >
> > How was the list of your root admins created? Who decided they would be 
> > root?
>
> while off topic and i think a flame bait.

Not off topic at all. You complain about irrelevant minutae of the
election and the election process, yet root admin access is controlled
entirely by you. And the latter is ok but the former in your mind is
not.

I do not want to be root. I host quite a bit of other non public
facing stuff for the project.

Regards,
Kieran Kunhya
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA

[Kieran Kunhya via ffmpeg-devel]

> The list does not match your list, for example Gautam is on your list
> but not on joshs
>
> So my question is still standing, can you explain how your list was created?
> or where its from?

How was the list of your root admins created? Who decided they would be root?

Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA

[Kieran Kunhya via ffmpeg-devel]

On Thu, Nov 9, 2023 at 5:06 PM Anton Khirnov  wrote:
>
> Quoting Michael Niedermayer (2023-11-09 17:21:12)
> > On Thu, Nov 09, 2023 at 01:21:13PM +0100, Anton Khirnov wrote:
> > > As far as I can tell, the voter list in the last vote should be the same
> > > as the GA from 2020, except for the extra members whose voting rights
> > > expire after 2 years.
> > >
> > > Do you dispute that?
> >
> > There are at least 3 issues here
> >
> > * The first and maybe the biggest, is that our vote superviser can reply to
> >   mails within 20min (like in this thread here) but is not replying to a 
> > simple
> >   question within days where the list of voters comes from he used and how 
> > it
> >   relates to the 2020 GA. It gives one the feeling he has some sort of
> >   difficulty with awnsering that question
> >   you took a guess here and replied, and i appreciate that. But really JB
> >   choose this list and also the one in 2020. Only he can explain where these
> >   lists come from and how they relate.
>
> JB did explain where the list comes from [1] - it was generated by the
> script that is now in our tree. Nobody disputed it in 2020.
>
> > * I know for a fact that at least zane was not in the 2020 GA as i talked
> >   with him and i know he did cast a vote in 2023 because again he told me.
> >   So even if you partially apply the rules these lists do not match
>
> Zane had 30 commits in July 2020, so he SHOULD have been on the list. If
> he wasn't, then it was a mistake in 2020.
>
> > * The 2nd issue is that there are rules how to change the GA over time
> >   like that after 2 years there needs to a confirmation AND that the
> >   other members represent the "active" developers in the last 36 months.
> >   I can see an argument to leave the 2020 GA untouched and use it as is
> >   I can also see an argument to update it, and exactly this was done in a
> >   vote in 2021 by JB. Now we are here trying the 3rd variant of applying
> >   only half the rules.
> >   But whats more so, we actually are not. What you are doing here is
> >   looking at what happened and trying to rationalize it, trying to find
> >   an explanation for the list. Not stating upfront what this list is
> >   IMO this is not acceptable for a vote. Uhm we found this list, lets see
> >   where that might have come from 
>
> To be honest, it very much seems to me that you are trying to bikeshed
> the process to death. Yes, it is imperfect, but that is to be expected
> given we've only used it a few times so far, and the last time was over
> 2 years ago. What we are doing here is trying to clarify the rules so
> that we actually can vote with some regularity.
>
> In the vote we just had, option A won its contests against B/C/D by
> 17/7, 23/1, and 17/7, respectively. While it is possible that the list
> used was not entirely correct (also depending on
> the intepretation of the rules), I see no reason to think it was
> incorrect in 10 people, which is what you'd need to have a chance of
> getting a different result.
>
> [1] http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2020-June/264732.html
>
> --
> Anton Khirnov

Organizations and Conferences

Insist on doing everything through “channels.” Never permit
short-cuts to be taken in order to expedite decisions.
Make “speeches.” Talk as frequently as possible and at great
length. Illustrate your “points” by long anecdotes and accounts of
personal experiences.
When possible, refer all matters to committees, for “further study
and consideration.” Attempt to make the committee as large as possible
— never less than five.
Bring up irrelevant issues as frequently as possible.
Haggle over precise wordings of communications, minutes, resolutions.
Refer back to matters decided upon at the last meeting and attempt
to re-open the question of the advisability of that decision.
Advocate “caution.” Be “reasonable” and urge your fellow-conferees
to be “reasonable” and avoid haste which might result in
embarrassments or difficulties later on.

source: 
https://www.forbes.com/sites/eriklarson/2023/08/15/a-spys-guide-to-making-bad-decisions/

Presented without comment.

Regards,
Kieran Kunhya
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Kieran Kunhya via ffmpeg-devel]

On Tue, Oct 3, 2023 at 7:50 PM Nicolas George  wrote:
> More precisely, I now strongly believe that democracy is a terrible way
> to run a project like FFmpeg.

Why are you part of a community project if you don't believe the
community is capable of running a project?
Why not start your own project like TempleOS where you can do what you want?

Kieran


Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Kieran Kunhya via ffmpeg-devel]

> Iam part of the community, i would think and for 99% of the tweets made
> on the official twitter account i have never been asked or even had a
> chance to comment before they where made. So what you suggest here is
> "the correct way", has never been applied.

Announcing feature are going to be present in a release in a tweet
that the community has no consensus on is not the same as making
general tweets about VDD, FFmpeg etc.

Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] FFmpeg release 6.1 (SDR Plans)

[Kieran Kunhya via ffmpeg-devel]

On Thu, Sep 21, 2023 at 5:21 PM Michael Niedermayer
 wrote:
> OTOH If a majority of people are against the SDR code at the time of
> branching 6.1. Then i will make a separate release identical to 6.1 with
> the SDR code and of course also provide security support

How on earth is it acceptable that you can publish your hobby project
under the FFmpeg project name?
You are of course welcome to publish SDR in a different project that
is not FFmpeg.

I have been working on BIOS code recently but I haven't decided to
create FFBIOS and put it in the main FFmpeg repo.

Regards,
Kieran Kunhya
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] X (Twitter) Access

[Kieran Kunhya via ffmpeg-devel]

Hello,

X (Twitter) has changed the way accounts can post under @ffmpeg.
Please could the person with the main login to @ffmpeg delegate myself
("kierank_") and Derek ("Daemon404") and delegate @ffmpeg access to
both of us.

We have tested this with the @videolan account and it works without a
blue tick for anyone.

Regards,
Kieran Kunhya
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".