[FFmpeg-devel] Re: [POLL][VOTE] Revoke social media delegation

[Steven Liu via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>]

Lynne via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> 于2025年10月27日周一 01:08写道：
>
> On 26/10/2025 16:26, Michael Niedermayer wrote:
> > Hi Everyone
> >
> > As requested, reposting this, as a new thread
> >
> > For context please see:
> > https://www.youtube.com/watch?v=3VkcAvqV24c
> > https://lists.ffmpeg.org/archives/list/ffmpeg-devel@ffmpeg.org/thread/PZL3NMBYJJ7RHEJ2NEGE26R2HHXKRQ2S/
> > Subject: Twitter/X spat on Youtube
> >
> > Should the delegation, from where this came from, be revoked to FFmpeg social media?
> > (vote ends in 7 days)
> >
> > Please reply on ffmpeg-devel with your choice:
> >
> > [R] revoke access
> >
> > [K] keep access
>
> K
+1
>
> I think Kieran has been doing a good job with our X account.
> His approach to spreading awareness about what we do may be
> unconventional and confrontational, but its this is how engagement works
> on social networks. And I like engagement - it gives our project a name,
> rather than simply being brick #23 in xkcd #2347.
>
> I looked at the video, and I failed to understand the author's points -
> he said how integration is difficult, and our reply of asking for
> patches was rude. Then he went off on a tangent that VLC releases are
> too far apart, then went on about how we have responsibilities to listen
> to and fix issues that large users of ffmpeg have, and our repeated
> response of asking for patches was rude, even though he has donated and
> built a company's infra using our code?
> We're volunteers, and we're absolved of responsibility of our code. As a
> project, we don't have to treat someone as special because they used our
> work or donated. Asking for patches is pretty standard - we even have an
> error code. By looking into issues and writing, you either fix the
> issue, or very quickly gain an appreciation for why the issue has not
> been fixed yet, in a way that goes beyond argument.
>
> Integration can be difficult to someone lacking knowledge of our APIs.
> We have a very low-level API. It's not something that can be improved
> specifically -- it gives API users freedom. From our community, there
> are projects that wrap the API to give users far easier time with
> decoding, seeking, filtering, and, encoding.
> There were plans to integrate a high-level API at some point, but
> there's enough of an ecosystem built around our existing API to give
> users a far wider choice in terms of abstractions and languages than an
> official high-level API.
> I do agree our project can be a pain to build and integrate - switching
> to meson would solve this as far as my use cases go, as well as many
> other projects using our libraries.
>
> Donations are appreciated as they help keep our infra going, as well as
> very rare trips and hardware when we agree on them, but we as developers
> don't have free access to them, so its difficult for us to gauge their
> impact beyond a number.
> An effective way of asking us to fix something is to approach us
> directly. Incidentally, if someone at Twitch or X is reading this, give
> me a call if you'd like to see our AAC encoder improved.
> _______________________________________________
> ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
> To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org