[FFmpeg-devel] Pagure for ffmpeg (was Re: VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin))
On Sun, Sep 24, 2023 at 6:09 AM Michael Niedermayer wrote: > > Hi > > Iam a little tired so expect a more tidy mail in a few days but i want to > reply with a few points immedeately as they seem important. > > > On Sun, Sep 24, 2023 at 09:37:03AM +0100, Kyle Swanson wrote: > > > > Gitlab (or something like Gitlab) > > - > > > > - Ronald is proposing that we move to Gitlab, or something similar > > (gitea). > > - Michael says "i don't like Gitlab"; Ronald says the exact tool is not > > important and we can work together to make sure that the new tool suits > > other styles of work, such as command line tools. > > > - No strong dissent in the room, acceptable to most. > > strong dissent by me against any move making FFmpeg more dependant on > other projects. (videolan or gitlhub or whatevr) > > also IMO major changes cannot be done with just 51% majority, thats not really > normal. > > iam not fundamentally against moving to better software (hell, why would i) > but trac and git work fine > and fate well, some fate clients are down since i moved one of my > boxes and forgot to restart them. And of course noone reminded me > (ill look into restarting them after this conference reminded me) > No SW is going to safe you of this sort of issue > > Also SW must be easy maintainable, everything i hear of gitlab is saying > the opposit. > It must be possible that when something happens to our servers no matter > if videolan or micosoft or our own. That everything can be recovered > and quickly put back in action without too much server admins cooperation > (they could be sick or arrested or joined the wrong FOSS cult) > plain git allows easy recovery, trac has backups in the hands > of multiple people (these backups are the drop it in a directory and start > it more or less kind IIRC) > > again IMO any change to what SW we use needs more discussion than a > "who likes gitlab, who likes gitwhatever" vote > At the risk of directing flames at myself, might I suggest maybe an ffmpeg Pagure deployment? Pagure (https://pagure.io/pagure) is a lightweight and extensible Git forge written in Python that has a few notable properties: * All project data is stored as Git repos (tickets, pull request metadata, docs sites, etc.) ** This means project backups, instance migrations, and restores are relatively easy * Pagure project maintainers can do bulk work offline and push whenever because of the above ** Pag-Off is an example tool: https://pagure.io/pag-off * Pagure supports a concept called "remote pull requests" where Pagure can be pointed to an arbitrary git branch on another git server to create a pull request * Pagure is packaged in a number of Linux distributions (offhand: Fedora, RHEL/CentOS, openSUSE, Mageia, Debian, Ubuntu, and Arch AUR) * Jenkins and Zuul CI integration exists for Pagure, and the API can be used to support others A long time ago, Fedora wrote a tool for importing stuff from Trac into Pagure: https://pagure.io/pagure-importer There's work going on right now for an upcoming 6.0 release, but the latest 5.x release is available in at least Fedora, RHEL/CentOS, and openSUSE. There are a few instances out in the wild already: * Reference: https://pagure.io * Fedora: https://src.fedoraproject.org * openSUSE: https://code.opensuse.org * CentOS: https://git.centos.org * Midipix: https://dev.midipix.org (Full disclosure, I'm a contributor to Pagure.) -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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)
On 9/24/2023 11:13 AM, Jean-Baptiste Kempf wrote: > What are you talking about? This is just people in the room, who asked to be > in the extra bucket, because they don't have the required commit numbers. It > does not mean it's the complete list. I do have the relevant commit numbers, I was informed, FWIW. I was mistaken. - Derek ___ 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] libswresample/swresample: avoid s16p internal transfer format
On Sat, Sep 23, 2023 at 11:32:28PM +0200, Paul B Mahol wrote: > On Sat, Sep 23, 2023 at 11:02 PM Michael Niedermayer > wrote: > > > From: Paul B Mahol > > > > Instead use float one by default for sample rate conversions. > > The s16p internal transfer format produces visible and hearable > > quantization artifacts. > > > > Signed-off-by: Paul B Mahol > > > > for S8 we continue to use S16 as it should have enough precision > > Fate is adjusted so bitexactness is maintained between mips/arm/x86 > > if more tests became bit-inexact on some platform, the same change > > can be done to them > > > > The use of higher precision and float intermediates inevitably > > leads to more differences between platforms. > > > > Could add S64 precision path, but would be slower than float, probably. > LGTM. will apply later without 2 lines (bugs noticed on rerunning with distclean) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "You are 36 times more likely to die in a bathtub than at the hands of a terrorist. Also, you are 2.5 times more likely to become a president and 2 times more likely to become an astronaut, than to die in a terrorist attack." -- Thoughty2 signature.asc Description: PGP signature ___ 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] libavdevice (was: FFmpeg release 6.1 (SDR Plans))
Paul B Mahol (12023-09-24): > libavdevice is using libavformat API that is unacceptable maintenance burden. This is a lie. You would not even know if libavdevice is a maintenance burden, you never touch it. -- Nicolas George signature.asc Description: PGP signature ___ 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] libavdevice (was: FFmpeg release 6.1 (SDR Plans))
On 9/24/23, Nicolas George wrote: > Paul B Mahol (12023-09-24): >> Citations needed. > > > >> libavdevice have no API. > > Yes, that was my point. If you do not understand why it is an essential > part of libavdevice, I suggest you take the time to learn what > libavdevice is all about and refrain from commenting on it before you > have gotten a clue. You are typical wannabe next-door tyrant. libavdevice is using libavformat API that is unacceptable maintenance burden. ___ 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] libavdevice (was: FFmpeg release 6.1 (SDR Plans))
Paul B Mahol (12023-09-24): > Citations needed. > libavdevice have no API. Yes, that was my point. If you do not understand why it is an essential part of libavdevice, I suggest you take the time to learn what libavdevice is all about and refrain from commenting on it before you have gotten a clue. -- Nicolas George signature.asc Description: PGP signature ___ 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] libavdevice (was: FFmpeg release 6.1 (SDR Plans))
On 9/24/23, Nicolas George wrote: > Paul B Mahol (12023-09-24): >> Define 'works'. >> >> It is clearly sub-optimal. > > Many users use it for many different tasks and it serves them > efficiently. > > There are probably ways to enhance the API of libavdevice. If you have > suggestions, then please share them. But when you say that libavdevices > is “abusing libavformat”, it seems to indicate you completely missed the > fact that being able to use devices in places that were not designed is > an essential part of the service libavdevice gives to users, and if your > suggestions involve breaking it you can keep them to yourself, they are > useless. Citations needed. > > As for people who criticize libavdevice without even a hint of a > reflection on how to make make it better, they are just hypocrites who > disguise their hate into technical opinion. libavdevice have no API. ___ 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] libavdevice (was: FFmpeg release 6.1 (SDR Plans))
Paul B Mahol (12023-09-24): > Define 'works'. > > It is clearly sub-optimal. Many users use it for many different tasks and it serves them efficiently. There are probably ways to enhance the API of libavdevice. If you have suggestions, then please share them. But when you say that libavdevices is “abusing libavformat”, it seems to indicate you completely missed the fact that being able to use devices in places that were not designed is an essential part of the service libavdevice gives to users, and if your suggestions involve breaking it you can keep them to yourself, they are useless. As for people who criticize libavdevice without even a hint of a reflection on how to make make it better, they are just hypocrites who disguise their hate into technical opinion. -- Nicolas George signature.asc Description: PGP signature ___ 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)
On 9/24/23, Nicolas George wrote: > Paul B Mahol (12023-09-24): >> libavdevice is abusing libavformat. >> >> It should have own API or be removed. > > libavdevice works. Define 'works'. It is clearly sub-optimal. ___ 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] [PATCH] dxa patch
Attached.
From 8863580694665ff33312829209b7aabc41ae1855 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Sun, 24 Sep 2023 19:28:40 +0200
Subject: [PATCH] avcodec/dxa: use uint8_t for type of arrays
Signed-off-by: Paul B Mahol
---
libavcodec/dxa.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/dxa.c b/libavcodec/dxa.c
index 650502ad23..d33ac3c8b0 100644
--- a/libavcodec/dxa.c
+++ b/libavcodec/dxa.c
@@ -45,8 +45,8 @@ typedef struct DxaDecContext {
uint32_t pal[256];
} DxaDecContext;
-static const int shift1[6] = { 0, 8, 8, 8, 4, 4 };
-static const int shift2[6] = { 0, 0, 8, 4, 0, 4 };
+static const uint8_t shift1[6] = { 0, 8, 8, 8, 4, 4 };
+static const uint8_t shift2[6] = { 0, 0, 8, 4, 0, 4 };
static int decode_13(AVCodecContext *avctx, DxaDecContext *c, uint8_t* dst,
int stride, uint8_t *src, int srcsize, uint8_t *ref)
--
2.42.0
___
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)
Michael Niedermayer (12023-09-24): > Also SW must be easy maintainable, everything i hear of gitlab is saying > the opposit. I have not read the rest of the message yet, for now I just want to mention that a non-negligible part of my job in the last year involved upgrading GitLab after emergency security releases. Regards, -- Nicolas George signature.asc Description: PGP signature ___ 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)
On Sun, Sep 24, 2023 at 04:10:00PM +0100, Ronald S. Bultje wrote: > Hi, > > On Sun, Sep 24, 2023 at 1:40 PM Marton Balint wrote: > > > On Sun, 24 Sep 2023, Kyle Swanson wrote: > > > DNS > > > --- > > > > > > - Currently the DNS of ffmpeg.org is managed by Fabrice > > > - Michael was asked if he has control over the ffmpeg.org DNS > > register. > > > - Michael says he thinks he has some. > > > - Ronald would be curious to know what "some" means. > > > - Ronald proposes current project owners should have control over DNS > > and > > > trademark. > > > - Ronald: Fabrice is not active, DNS and trademark should be in the > > > control of project members. > > > - Michael: "i think fabrice should stay in ultimate control", "he has > > > always acted in the best interests of the people". > > > - Ronald took a poll in the room, most agreed current project > > developers > > > should have control of this. > > > > I think you should define what you are aiming for exactly. Having more > > people control the domain zone, or asking Fabrice to transfer domain > > ownership to someone else or some legal entity. > > > > I doubt anybody has problem with the former, but for the latter, knowing > > history, it will certainly raise eyebrows. IMHO having Fabrice ultimate > > control over the domain ensures that everybody plays nice. > > > > I disagree. > > Fabrice has theoretical veto power over anything this community does > because he can change the IP ffmpeg.org points to. That is not right. He is > not a participant anymore. I understand he conceived of the project and its > name, but he is no longer part of the developer community in this project. > Most participants (basically everyone) agreed with this. > > I don't mean to threaten and I don't mean to own rights to anything myself. > If you don't like me asking to be part of the GA even though I don't meet > the commit count threshold, you can express that by denying me membership > in the "other people" vote that will be up at some point in the near > future. I will respect this process regardless of outcome. > > I believe the GA should have sole control and ownership over the domain and > trademark. I suggested to kindly ask Fabrice to transfer ownership and/or > legal control permanently to a non-profit controlled by and composed of > only our GA. I believe this can be amicably worked out. If you believe > Fabrice should continue to have *some* (although not *sole*) say over > FFmpeg and ffmpeg.org, then we could propose for him to be a GA member, > too. I think that makes a lot of sense - he historically has a ton more > work in FFmpeg than me. I disagree * Who is and is not a member of the GA is in flux, there can be disputes even on GA membership. * You cannot have something owned by a group like that. There needs to be an individual like a treassurer who has the actual key. So you again trust one person, this is not different from what it is now. Also democracies can make really bad decissions. Which iam sure you have never seen occur ;) And last but not least, this is attackable even unintentionally you just need for a single moment a majority in the GA that is bad. This is not hard to reach, a group can easily pose as enough active developers to achieve 51% and if the domain then really is legally controlled by the GA. yeah goodby domain this is not a scenario possible with fabrice having theretical veto power. So Yes, i strongly favor fabrice keeping this veto power. And sure i can probably word above mail more convincingly if i go over it 3 times and send it tomorrow but i belive you understand my point even with it just roughly worded thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: PGP signature ___ 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] [PATCH 3/3] fate/ffprobe: FATE antiyellow --disable-avfilter
Signed-off-by: Michael Niedermayer --- tests/fate/ffprobe.mak | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tests/fate/ffprobe.mak b/tests/fate/ffprobe.mak index d2abe8a11e1..ee76a0dab3f 100644 --- a/tests/fate/ffprobe.mak +++ b/tests/fate/ffprobe.mak @@ -35,7 +35,8 @@ fate-ffprobe_xsd: CMD = run $(FFPROBE_COMMAND) -noprivate -of xml=q=1:x=1 | \ xmllint --schema $(SRC_PATH)/doc/ffprobe.xsd - FATE_FFPROBE-$(HAVE_XMLLINT) += $(FATE_FFPROBE_SCHEMA-yes) -FATE_FFPROBE += $(FATE_FFPROBE-yes) +FATE_FFPROBE_FF-$(CONFIG_FFMPEG) += $(FATE_FFPROBE-yes) +FATE_FFPROBE += $(FATE_FFPROBE_FF-yes) fate-ffprobe: $(FATE_FFPROBE) -- 2.17.1 ___ 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] [PATCH 2/3] fate/api: FATE antiyellow --disable-avfilter
Signed-off-by: Michael Niedermayer --- tests/fate/api.mak | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/fate/api.mak b/tests/fate/api.mak index 688fc0f9b39..ebdedd3ff5b 100644 --- a/tests/fate/api.mak +++ b/tests/fate/api.mak @@ -16,7 +16,7 @@ FATE_API_SAMPLES_LIBAVFORMAT-$(call DEMDEC, H264, H264) += fate-api-h264-slice fate-api-h264-slice: $(APITESTSDIR)/api-h264-slice-test$(EXESUF) fate-api-h264-slice: CMD = run $(APITESTSDIR)/api-h264-slice-test$(EXESUF) 2 $(TARGET_SAMPLES)/h264/crew_cif.nal -FATE_API_LIBAVFORMAT-$(call DEMDEC, FLV, FLV) += fate-api-seek +FATE_API_LIBAVFORMAT-$(call ALLYES, FFMPEG FLV_DEMUXER FLV_DECODER) += fate-api-seek fate-api-seek: $(APITESTSDIR)/api-seek-test$(EXESUF) fate-lavf-flv fate-lavf-flv: KEEP_FILES ?= 1 fate-api-seek: CMD = run $(APITESTSDIR)/api-seek-test$(EXESUF) $(TARGET_PATH)/tests/data/lavf/lavf.flv 0 720 -- 2.17.1 ___ 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] [PATCH 1/3] tests/fate/libswscale: Fixing yellow fate
Signed-off-by: Michael Niedermayer --- tests/fate/libswscale.mak | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/fate/libswscale.mak b/tests/fate/libswscale.mak index f8572f9c37b..f2dcd352560 100644 --- a/tests/fate/libswscale.mak +++ b/tests/fate/libswscale.mak @@ -17,7 +17,7 @@ $(SWS_SLICE_TEST-yes): tools/scale_slice_test$(EXESUF) $(SWS_SLICE_TEST-yes): REF = /dev/null FATE_LIBSWSCALE_SAMPLES += $(SWS_SLICE_TEST-yes) -FATE_LIBSWSCALE-$(CONFIG_RAWVIDEO_DEMUXER) += fate-sws-yuv-colorspace +FATE_LIBSWSCALE-$(call ALLYES, FFMPEG RAWVIDEO_DEMUXER) += fate-sws-yuv-colorspace fate-sws-yuv-colorspace: tests/data/vsynth1.yuv fate-sws-yuv-colorspace: ffmpeg$(PROGSSUF)$(EXESUF) fate-sws-yuv-colorspace: CMD = framecrc \ @@ -25,7 +25,7 @@ fate-sws-yuv-colorspace: CMD = framecrc \ -frames 1 \ -vf scale=in_color_matrix=bt709:in_range=limited:out_color_matrix=bt601:out_range=full:flags=+accurate_rnd+bitexact -FATE_LIBSWSCALE-$(CONFIG_RAWVIDEO_DEMUXER) += fate-sws-yuv-range +FATE_LIBSWSCALE-$(call ALLYES, FFMPEG RAWVIDEO_DEMUXER) += fate-sws-yuv-range fate-sws-yuv-range: tests/data/vsynth1.yuv fate-sws-yuv-range: ffmpeg$(PROGSSUF)$(EXESUF) fate-sws-yuv-range: CMD = framecrc \ -- 2.17.1 ___ 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)
Hi Michael, On Sun, Sep 24, 2023 at 11:09 AM Michael Niedermayer wrote: > On Sun, Sep 24, 2023 at 09:37:03AM +0100, Kyle Swanson wrote: > > Gitlab (or something like Gitlab) > > - > > > > - Ronald is proposing that we move to Gitlab, or something similar > > (gitea). > > - Michael says "i don't like Gitlab"; Ronald says the exact tool is not > > important and we can work together to make sure that the new tool suits > > other styles of work, such as command line tools. > > > - No strong dissent in the room, acceptable to most. > > strong dissent by me against any move making FFmpeg more dependant on > other projects. (videolan or gitlhub or whatevr) > > also IMO major changes cannot be done with just 51% majority, thats not > really > normal. > > iam not fundamentally against moving to better software (hell, why would i) > but trac and git work fine > and fate well, some fate clients are down since i moved one of my > boxes and forgot to restart them. And of course noone reminded me > (ill look into restarting them after this conference reminded me) > No SW is going to safe you of this sort of issue > > Also SW must be easy maintainable, everything i hear of gitlab is saying > the opposit. > It must be possible that when something happens to our servers no matter > if videolan or micosoft or our own. That everything can be recovered > and quickly put back in action without too much server admins cooperation > (they could be sick or arrested or joined the wrong FOSS cult) > plain git allows easy recovery, trac has backups in the hands > of multiple people (these backups are the drop it in a directory and start > it more or less kind IIRC) > > again IMO any change to what SW we use needs more discussion than a > "who likes gitlab, who likes gitwhatever" vote > Briefly: don't expect any quick activity here that affects anyone. My goal here was to see if we (as a GA) can find some kind of consensus to look into alternatives to our current trac/patchwork/fate/git workflow. That doesn't mean everything is bad: git is great. I find the "integrated developer experience" very lacking, though. We use a different system in dav1d and it is by far superior. (Please voice your +1/-1 here.) There are many important details to be worked out and kinks to be resolved. Michael named some. I agree with most of what Michael says. Own control is critical, and we should not rely on outside parties. Anton had a whole bunch also, for example about commandline accessibility of the full feature set of a developer workflow, including efficient patch review that does not require a web browser. I agree with that also. I don't mean to take your workflow away from you. Ronald ___ 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)
Hi, On Sun, Sep 24, 2023 at 1:40 PM Marton Balint wrote: > On Sun, 24 Sep 2023, Kyle Swanson wrote: > > DNS > > --- > > > > - Currently the DNS of ffmpeg.org is managed by Fabrice > > - Michael was asked if he has control over the ffmpeg.org DNS > register. > > - Michael says he thinks he has some. > > - Ronald would be curious to know what "some" means. > > - Ronald proposes current project owners should have control over DNS > and > > trademark. > > - Ronald: Fabrice is not active, DNS and trademark should be in the > > control of project members. > > - Michael: "i think fabrice should stay in ultimate control", "he has > > always acted in the best interests of the people". > > - Ronald took a poll in the room, most agreed current project > developers > > should have control of this. > > I think you should define what you are aiming for exactly. Having more > people control the domain zone, or asking Fabrice to transfer domain > ownership to someone else or some legal entity. > > I doubt anybody has problem with the former, but for the latter, knowing > history, it will certainly raise eyebrows. IMHO having Fabrice ultimate > control over the domain ensures that everybody plays nice. > I disagree. Fabrice has theoretical veto power over anything this community does because he can change the IP ffmpeg.org points to. That is not right. He is not a participant anymore. I understand he conceived of the project and its name, but he is no longer part of the developer community in this project. Most participants (basically everyone) agreed with this. I don't mean to threaten and I don't mean to own rights to anything myself. If you don't like me asking to be part of the GA even though I don't meet the commit count threshold, you can express that by denying me membership in the "other people" vote that will be up at some point in the near future. I will respect this process regardless of outcome. I believe the GA should have sole control and ownership over the domain and trademark. I suggested to kindly ask Fabrice to transfer ownership and/or legal control permanently to a non-profit controlled by and composed of only our GA. I believe this can be amicably worked out. If you believe Fabrice should continue to have *some* (although not *sole*) say over FFmpeg and ffmpeg.org, then we could propose for him to be a GA member, too. I think that makes a lot of sense - he historically has a ton more work in FFmpeg than me. Ronald ___ 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)
On Sun, Sep 24, 2023 at 02:36:20PM +0200, Marton Balint wrote: > > > On Sun, 24 Sep 2023, Kyle Swanson wrote: > > > DNS > > --- > > > > - Currently the DNS of ffmpeg.org is managed by Fabrice > > - Michael was asked if he has control over the ffmpeg.org DNS register. > > - Michael says he thinks he has some. > > - Ronald would be curious to know what "some" means. > > - Ronald proposes current project owners should have control over DNS and > > trademark. > > - Ronald: Fabrice is not active, DNS and trademark should be in the > > control of project members. > > - Michael: "i think fabrice should stay in ultimate control", "he has > > always acted in the best interests of the people". > > - Ronald took a poll in the room, most agreed current project developers > > should have control of this. > > I think you should define what you are aiming for exactly. Having more > people control the domain zone, [...] currently all the root admins can update the zone file on the main DNS server and it will then get pulled to the DNS slaves from there I guess i have been the one updating it most of the time but the other admins can too. I also think updates have always been done quickly And its rare that something needs to be changed in it. like if between https://fatebeta.ffmpeg.org/ and http://coverage.ffmpeg.org/ you want to setup a fategamma.ffmpeg.org ... thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin signature.asc Description: PGP signature ___ 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)
On Sun, 24 Sep 2023, Kyle Swanson wrote: DNS --- - Currently the DNS of ffmpeg.org is managed by Fabrice - Michael was asked if he has control over the ffmpeg.org DNS register. - Michael says he thinks he has some. - Ronald would be curious to know what "some" means. - Ronald proposes current project owners should have control over DNS and trademark. - Ronald: Fabrice is not active, DNS and trademark should be in the control of project members. - Michael: "i think fabrice should stay in ultimate control", "he has always acted in the best interests of the people". - Ronald took a poll in the room, most agreed current project developers should have control of this. I think you should define what you are aiming for exactly. Having more people control the domain zone, or asking Fabrice to transfer domain ownership to someone else or some legal entity. I doubt anybody has problem with the former, but for the latter, knowing history, it will certainly raise eyebrows. IMHO having Fabrice ultimate control over the domain ensures that everybody plays nice. Regards, Marton ___ 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)
Paul B Mahol (12023-09-24): > libavdevice is abusing libavformat. > > It should have own API or be removed. libavdevice works. -- Nicolas George signature.asc Description: PGP signature ___ 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)
On Sun, Sep 24, 2023 at 11:12 AM Nicolas George wrote: > Neal Gompa (12023-09-23): > > If it's just taking SDR devices as inputs and allowing you to encode > > audio and video streams, I'm not sure why you *wouldn't* have this as > > something in libavdevice or extended from it as a separate library. > > The people who oppose Michael's SDR also have been trying to kill > libavdevice for years. At least some of them. > libavdevice is abusing libavformat. It should have own API or be removed. > > Regards, > > -- > Nicolas George > ___ > 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] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)
>> General Assembly, Candidates (J-B will mail a vote): >> - BBB >> - Derek > > Quite interresting that every single developer who probably isnt going > to support > some of the significant changes proposed later disappeared from the > Previous > Candidates What are you talking about? This is just people in the room, who asked to be in the extra bucket, because they don't have the required commit numbers. It does not mean it's the complete list. >> Community Committee, Candidates (J-B will mail a vote): >> - Dave Rice >> - James >> - J-B >> - Thilo >> - Steven >> - BBB > > Iam missing carl on the list As above. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ 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 PATCH 0/3] Propagate PRFT side data
Hi, I plan to resent this series without the latest patch. Regarding Patch 1 and 2 do you have any comment? One thing is that unlike the decode.c which has a common ff_decode_frame_props_from_pkt() there is no such thing for the encode part. Or maybe I missed it ? I noticed that the propagation of this data doesn't work when I enable the hardware Nvidia encoder. Does it make sense to introduce a ff_encode_packet_props_from_frame()? Thanks, On Thu, 21 Sept 2023 at 17:41, Clément Péron wrote: > > Hi Kieran, > > On Thu, 21 Sept 2023 at 15:13, Kieran Kunhya wrote: > > > > On Thu, 21 Sept 2023, 13:17 Clément Péron, wrote: > >> > >> 4I have a project where I need to synchronize multiple RTSP cameras with > >> other > >> network sensors (sync with NTP or PTP). > > > > > > Just be aware the clock of the vast majority of cameras have no relation to > > NTP or PTP so you will have drift and need to handle that (e.g by dropping > > or duplicating frames). > > Thanks for pointing this out, and yes I consider each of my sensors > running on a free clock and I recreate a "virtual frame" that is not > correlated to the FPS of each sensor. > > Thanks, > Clement > > > > > 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)
Neal Gompa (12023-09-23): > If it's just taking SDR devices as inputs and allowing you to encode > audio and video streams, I'm not sure why you *wouldn't* have this as > something in libavdevice or extended from it as a separate library. The people who oppose Michael's SDR also have been trying to kill libavdevice for years. At least some of them. Regards, -- Nicolas George signature.asc Description: PGP signature ___ 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".
