Re: [FFmpeg-devel] [PATCH] cmdutils: fix printing of codecs
On Thu, Feb 08, 2018 at 06:21:06PM +0100, wm4 wrote: > On Thu, 8 Feb 2018 12:34:07 -0300 > James Almer wrote: > > > On 2/8/2018 7:25 AM, Rostislav Pehlivanov wrote: > > > On 8 February 2018 at 10:06, Nicolas George wrote: > > > > > >> Michael Niedermayer (2018-02-08): > > >>> +1 > > >> > > >> I agree too. > > >> > > >> And maybe, since we are reverting something, revert the whole series. > > >> > > >> Regards, > > >> > > >> -- > > >> Nicolas George > > >> > > >> ___ > > >> ffmpeg-devel mailing list > > >> ffmpeg-devel@ffmpeg.org > > >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > >> > > >> > > > > > > -1, I object to reverting anything. > > > We should fix what we have right now. The API looks good too except some > > > people here feel like they haven't bikeshedded enough and want to cause > > > even more chaos. > > > One bad commit and you all go screaming revert with your pitchforks > > > instead > > > of trying to fix it. > > > > A set of seven patches was pushed before any of them got a full review > > or even an ok, which unsurprisingly introduced a plethora of issues, and > > all while there were discussions going about implementing the API in a > > different way by more than one developer. > > I do not, under any circumstance, support this strategy of pushing > > unfinished things and then argue that since it's already committed it > > can't be touched. I have no idea how you or anyone could support this > > kind of thing. > > > > The entire set should be reverted if only to make it clear that this is > > not how development should work, yet everyone so far, including myself, > > has suggested to only revert the one non-API commit that badly broke a > > lot of things, then work on top of the already introduced API to > > effectively finalize it, and then fix and reapply any implementation bits. > > The author spent weeks on fixing all the issues, updating the patch set > multiple times, and so on. In the end, he didn't get much helpful > reviews, but tons of bikeshedding that was unproductive as hell. Also > it seems he formally didn't violate any rules, because he fixed the > issues and waited long enough. Theres no need to polarize the discussion any further. neither attacking anyone nor glorifying the author of a patchset with a inprecisse statement where a correction would likely insult the author. iam sure he is already stressed from having pushed a patchset that introduced some issues. We are one team, if WE have a bug in the code we should fix it or revert the patch causing it. If a issue is trivial to fix then fixing is better. If it is complex and one works under pressure its likely better to revert so as not to introduce more mistakes and have a clean known to work basis ... Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cmdutils: fix printing of codecs
On Thu, 8 Feb 2018 12:34:07 -0300 James Almer wrote: > On 2/8/2018 7:25 AM, Rostislav Pehlivanov wrote: > > On 8 February 2018 at 10:06, Nicolas George wrote: > > > >> Michael Niedermayer (2018-02-08): > >>> +1 > >> > >> I agree too. > >> > >> And maybe, since we are reverting something, revert the whole series. > >> > >> Regards, > >> > >> -- > >> Nicolas George > >> > >> ___ > >> ffmpeg-devel mailing list > >> ffmpeg-devel@ffmpeg.org > >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >> > >> > > > > -1, I object to reverting anything. > > We should fix what we have right now. The API looks good too except some > > people here feel like they haven't bikeshedded enough and want to cause > > even more chaos. > > One bad commit and you all go screaming revert with your pitchforks instead > > of trying to fix it. > > A set of seven patches was pushed before any of them got a full review > or even an ok, which unsurprisingly introduced a plethora of issues, and > all while there were discussions going about implementing the API in a > different way by more than one developer. > I do not, under any circumstance, support this strategy of pushing > unfinished things and then argue that since it's already committed it > can't be touched. I have no idea how you or anyone could support this > kind of thing. > > The entire set should be reverted if only to make it clear that this is > not how development should work, yet everyone so far, including myself, > has suggested to only revert the one non-API commit that badly broke a > lot of things, then work on top of the already introduced API to > effectively finalize it, and then fix and reapply any implementation bits. The author spent weeks on fixing all the issues, updating the patch set multiple times, and so on. In the end, he didn't get much helpful reviews, but tons of bikeshedding that was unproductive as hell. Also it seems he formally didn't violate any rules, because he fixed the issues and waited long enough. And now that some breakages occurred (which is not that surprising since the patch changes so much), most mails on this topic are STILL unhelpful bikeshedding. Keeping patches in bikeshed hell while not giving good reviews (like Michael just posting a specific command line and then saying "it broke" while not saying anything actually helpful, or certain other devs who came up with almost equivalent ideas how the components should be iterated but which they have unusually strong opinions about), is a good way to make developers leave and to make the mood of the project worse. Just saying. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cmdutils: fix printing of codecs
On 2/8/2018 1:16 PM, Rostislav Pehlivanov wrote: > On 8 February 2018 at 13:19, James Almer wrote: > >> On 2/8/2018 9:52 AM, wm4 wrote: >>> On Thu, 8 Feb 2018 10:29:11 + >>> Rostislav Pehlivanov wrote: >>> On 8 February 2018 at 01:08, Muhammad Faiz wrote: > On Thu, Feb 8, 2018 at 7:35 AM, James Almer wrote: >> On 2/7/2018 9:32 PM, Michael Niedermayer wrote: >>> On Wed, Feb 07, 2018 at 09:07:39PM +, Josh de Kock wrote: Yes, my bad. It looked like it worked initially (was more worried about getting a fix out quickly), but it didnt. Try this >> one. --- fftools/cmdutils.c | 104 +- > --- 1 file changed, 58 insertions(+), 46 deletions(-) >>> >>> I dont know if this is supposed to fix the other lists >>> but >>> ./ffmpeg -demuxers >>> still returns nonsense with this patch >>> >>> File formats: >>> D. = Demuxing supported >>> .E = Muxing supported >>> -- >>> E 3dostr 3DO STR >>> E 4xm 4X Technologies >>> ... >>> a while ago this was returned: >>> >>> File formats: >>> D. = Demuxing supported >>> .E = Muxing supported >>> -- >>> D 3dostr 3DO STR >>> D 4xm 4X Technologies >> >> Perhaps cdc78058c78dfa4966758a342acd2c1f3b282c46 should be reverted >> then. If the new API may actually get changed in the coming days once >> some consensus is reached then there's no point trying to get this >> working with things as is. > > +1. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > -1, there's no point in reverting this and then arguing for 3 weeks with people who will never use the API in the first place, don't understand >> the problem this patchset solved and just want to see their way be the only >> way things are done. We should fix this patch, fix another one if there's any and it'll be >> fine. >>> >>> +1 to this, but on the other hand this patch is just for code that >>> _uses_ the new API, not the API itself. >> >> Precisely. This is code implementing API that may or may not change, so >> there's no point trying to fix it if it may eventually have to be >> reverted anyway if we decide to use a different API. >> >> So revert this patch now, finalize and fix the new functions, then re >> apply it in a working way if needed afterwards. >> > > Seems reasonable. The author won't revert for some reason so could you go > ahead and do it? Done. Thanks. This most assuredly does not fix the issues introduced by the other patches that Michael reported, so those do need to be fixed, regardless of what's done with the API. > > >> >>> >>> I seriously hope nobody is arguing for reverting the API as is. It >>> didn't please everyone, but it's good and sufficient enough, and we >>> were in a bikeshed stalemate. >> >> No, the idea is to work on top of what's already committed, but do it ASAP. >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cmdutils: fix printing of codecs
On 8 February 2018 at 13:19, James Almer wrote: > On 2/8/2018 9:52 AM, wm4 wrote: > > On Thu, 8 Feb 2018 10:29:11 + > > Rostislav Pehlivanov wrote: > > > >> On 8 February 2018 at 01:08, Muhammad Faiz wrote: > >> > >>> On Thu, Feb 8, 2018 at 7:35 AM, James Almer wrote: > On 2/7/2018 9:32 PM, Michael Niedermayer wrote: > > On Wed, Feb 07, 2018 at 09:07:39PM +, Josh de Kock wrote: > >> Yes, my bad. It looked like it worked initially (was more > >> worried about getting a fix out quickly), but it didnt. Try this > one. > >> > >> --- > >> fftools/cmdutils.c | 104 +- > >>> --- > >> 1 file changed, 58 insertions(+), 46 deletions(-) > > > > I dont know if this is supposed to fix the other lists > > but > > ./ffmpeg -demuxers > > still returns nonsense with this patch > > > > File formats: > > D. = Demuxing supported > > .E = Muxing supported > > -- > > E 3dostr 3DO STR > > E 4xm 4X Technologies > > ... > > a while ago this was returned: > > > > File formats: > > D. = Demuxing supported > > .E = Muxing supported > > -- > > D 3dostr 3DO STR > > D 4xm 4X Technologies > > Perhaps cdc78058c78dfa4966758a342acd2c1f3b282c46 should be reverted > then. If the new API may actually get changed in the coming days once > some consensus is reached then there's no point trying to get this > working with things as is. > >>> > >>> +1. > >>> ___ > >>> ffmpeg-devel mailing list > >>> ffmpeg-devel@ffmpeg.org > >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >>> > >> > >> -1, there's no point in reverting this and then arguing for 3 weeks with > >> people who will never use the API in the first place, don't understand > the > >> problem this patchset solved and just want to see their way be the only > way > >> things are done. > >> We should fix this patch, fix another one if there's any and it'll be > fine. > > > > +1 to this, but on the other hand this patch is just for code that > > _uses_ the new API, not the API itself. > > Precisely. This is code implementing API that may or may not change, so > there's no point trying to fix it if it may eventually have to be > reverted anyway if we decide to use a different API. > > So revert this patch now, finalize and fix the new functions, then re > apply it in a working way if needed afterwards. > Seems reasonable. The author won't revert for some reason so could you go ahead and do it? > > > > > I seriously hope nobody is arguing for reverting the API as is. It > > didn't please everyone, but it's good and sufficient enough, and we > > were in a bikeshed stalemate. > > No, the idea is to work on top of what's already committed, but do it ASAP. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cmdutils: fix printing of codecs
On 2/8/2018 7:25 AM, Rostislav Pehlivanov wrote: > On 8 February 2018 at 10:06, Nicolas George wrote: > >> Michael Niedermayer (2018-02-08): >>> +1 >> >> I agree too. >> >> And maybe, since we are reverting something, revert the whole series. >> >> Regards, >> >> -- >> Nicolas George >> >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> > > -1, I object to reverting anything. > We should fix what we have right now. The API looks good too except some > people here feel like they haven't bikeshedded enough and want to cause > even more chaos. > One bad commit and you all go screaming revert with your pitchforks instead > of trying to fix it. A set of seven patches was pushed before any of them got a full review or even an ok, which unsurprisingly introduced a plethora of issues, and all while there were discussions going about implementing the API in a different way by more than one developer. I do not, under any circumstance, support this strategy of pushing unfinished things and then argue that since it's already committed it can't be touched. I have no idea how you or anyone could support this kind of thing. The entire set should be reverted if only to make it clear that this is not how development should work, yet everyone so far, including myself, has suggested to only revert the one non-API commit that badly broke a lot of things, then work on top of the already introduced API to effectively finalize it, and then fix and reapply any implementation bits. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cmdutils: fix printing of codecs
On 2/8/2018 9:52 AM, wm4 wrote: > On Thu, 8 Feb 2018 10:29:11 + > Rostislav Pehlivanov wrote: > >> On 8 February 2018 at 01:08, Muhammad Faiz wrote: >> >>> On Thu, Feb 8, 2018 at 7:35 AM, James Almer wrote: On 2/7/2018 9:32 PM, Michael Niedermayer wrote: > On Wed, Feb 07, 2018 at 09:07:39PM +, Josh de Kock wrote: >> Yes, my bad. It looked like it worked initially (was more >> worried about getting a fix out quickly), but it didnt. Try this one. >> >> --- >> fftools/cmdutils.c | 104 +- >>> --- >> 1 file changed, 58 insertions(+), 46 deletions(-) > > I dont know if this is supposed to fix the other lists > but > ./ffmpeg -demuxers > still returns nonsense with this patch > > File formats: > D. = Demuxing supported > .E = Muxing supported > -- > E 3dostr 3DO STR > E 4xm 4X Technologies > ... > a while ago this was returned: > > File formats: > D. = Demuxing supported > .E = Muxing supported > -- > D 3dostr 3DO STR > D 4xm 4X Technologies Perhaps cdc78058c78dfa4966758a342acd2c1f3b282c46 should be reverted then. If the new API may actually get changed in the coming days once some consensus is reached then there's no point trying to get this working with things as is. >>> >>> +1. >>> ___ >>> ffmpeg-devel mailing list >>> ffmpeg-devel@ffmpeg.org >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>> >> >> -1, there's no point in reverting this and then arguing for 3 weeks with >> people who will never use the API in the first place, don't understand the >> problem this patchset solved and just want to see their way be the only way >> things are done. >> We should fix this patch, fix another one if there's any and it'll be fine. > > +1 to this, but on the other hand this patch is just for code that > _uses_ the new API, not the API itself. Precisely. This is code implementing API that may or may not change, so there's no point trying to fix it if it may eventually have to be reverted anyway if we decide to use a different API. So revert this patch now, finalize and fix the new functions, then re apply it in a working way if needed afterwards. > > I seriously hope nobody is arguing for reverting the API as is. It > didn't please everyone, but it's good and sufficient enough, and we > were in a bikeshed stalemate. No, the idea is to work on top of what's already committed, but do it ASAP. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cmdutils: fix printing of codecs
On Thu, 8 Feb 2018 12:03:22 + Rostislav Pehlivanov wrote: > On 8 February 2018 at 10:35, Nicolas George wrote: > > > Rostislav Pehlivanov (2018-02-08): > > > We should fix what we have right now. The API looks good too except some > > > people here feel like they haven't bikeshedded enough and want to cause > > > even more chaos. > > > > Do you realize that sentence accuses Michael, Muhammad and me of > > pursuing a personal power trip instead of seeking the good of the > > project? Do you realize how incredibly insulting you are? > > > > Regards, > > > > -- > > Nicolas George > > > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > > No, I was referring to you and you alone. > You've been more insulting towards the people who do hard work and submit > patches by going out of your way to block them and saying "The burden of > proof is on you!". And by saying this you're basically not even wanting to > review anything - you'd rather be spoonfed some facts than look at the > code, figure out what it does, what it changes and seeing whether it's > doing what its meant to do or not. > If you want to be taken seriously and not be seen as someone as insulting > as you think I was here then you should provide constructive criticism, use > quotes, provide some information where you think there's an issue and > finally propose an alternative. So far you've only done "I don't like this > API and I can't be convinced otherwise!" and act surprised when your > rhetoric to revert everything was criticized. Meanwhile mfcc64 provided all > I just said and michaelni provided objective testing, so don't even compare > yourself to them. > Instead, why don't you send a patch or even a WIP of what you think ought > to be done to the API? You can add that his attitude sometimes leads to worse results too (instead of better ones, as he argues). Like the UDP EOF change, that ended in changing the libavformat API away from POSIX-like semantics in a way that caused tons of bugs (and some are still unfixed). Now I don't want to insult Nicolas or make him look incompetent in any way, but this is an attitude problem that needs to be fixed somehow. (I know he'll feel insulted by these words anyway - nothing you can do I guess.) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cmdutils: fix printing of codecs
On Thu, 8 Feb 2018 10:29:11 + Rostislav Pehlivanov wrote: > On 8 February 2018 at 01:08, Muhammad Faiz wrote: > > > On Thu, Feb 8, 2018 at 7:35 AM, James Almer wrote: > > > On 2/7/2018 9:32 PM, Michael Niedermayer wrote: > > >> On Wed, Feb 07, 2018 at 09:07:39PM +, Josh de Kock wrote: > > >>> Yes, my bad. It looked like it worked initially (was more > > >>> worried about getting a fix out quickly), but it didnt. Try this one. > > >>> > > >>> --- > > >>> fftools/cmdutils.c | 104 +- > > --- > > >>> 1 file changed, 58 insertions(+), 46 deletions(-) > > >> > > >> I dont know if this is supposed to fix the other lists > > >> but > > >> ./ffmpeg -demuxers > > >> still returns nonsense with this patch > > >> > > >> File formats: > > >> D. = Demuxing supported > > >> .E = Muxing supported > > >> -- > > >> E 3dostr 3DO STR > > >> E 4xm 4X Technologies > > >> ... > > >> a while ago this was returned: > > >> > > >> File formats: > > >> D. = Demuxing supported > > >> .E = Muxing supported > > >> -- > > >> D 3dostr 3DO STR > > >> D 4xm 4X Technologies > > > > > > Perhaps cdc78058c78dfa4966758a342acd2c1f3b282c46 should be reverted > > > then. If the new API may actually get changed in the coming days once > > > some consensus is reached then there's no point trying to get this > > > working with things as is. > > > > +1. > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > -1, there's no point in reverting this and then arguing for 3 weeks with > people who will never use the API in the first place, don't understand the > problem this patchset solved and just want to see their way be the only way > things are done. > We should fix this patch, fix another one if there's any and it'll be fine. +1 to this, but on the other hand this patch is just for code that _uses_ the new API, not the API itself. I seriously hope nobody is arguing for reverting the API as is. It didn't please everyone, but it's good and sufficient enough, and we were in a bikeshed stalemate. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cmdutils: fix printing of codecs
On 2/8/2018 7:29 AM, Rostislav Pehlivanov wrote: > On 8 February 2018 at 01:08, Muhammad Faiz wrote: > >> On Thu, Feb 8, 2018 at 7:35 AM, James Almer wrote: >>> On 2/7/2018 9:32 PM, Michael Niedermayer wrote: On Wed, Feb 07, 2018 at 09:07:39PM +, Josh de Kock wrote: > Yes, my bad. It looked like it worked initially (was more > worried about getting a fix out quickly), but it didnt. Try this one. > > --- > fftools/cmdutils.c | 104 +- >> --- > 1 file changed, 58 insertions(+), 46 deletions(-) I dont know if this is supposed to fix the other lists but ./ffmpeg -demuxers still returns nonsense with this patch File formats: D. = Demuxing supported .E = Muxing supported -- E 3dostr 3DO STR E 4xm 4X Technologies ... a while ago this was returned: File formats: D. = Demuxing supported .E = Muxing supported -- D 3dostr 3DO STR D 4xm 4X Technologies >>> >>> Perhaps cdc78058c78dfa4966758a342acd2c1f3b282c46 should be reverted >>> then. If the new API may actually get changed in the coming days once >>> some consensus is reached then there's no point trying to get this >>> working with things as is. >> >> +1. >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> > > -1, there's no point in reverting this and then arguing for 3 weeks with > people who will never use the API in the first place, don't understand the > problem this patchset solved and just want to see their way be the only way > things are done. > We should fix this patch, fix another one if there's any and it'll be fine. So you fix it now, then after discussing, we decide that we prefer to keep the _next style of API instead of _iterate. What happens then? This patch plus your fix will get reverted as they don't apply anymore. So i insist, revert this patch, finalize (and fix the issues in) the actual API, then start implementing it across the codebase. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cmdutils: fix printing of codecs
On 8 February 2018 at 10:35, Nicolas George wrote: > Rostislav Pehlivanov (2018-02-08): > > We should fix what we have right now. The API looks good too except some > > people here feel like they haven't bikeshedded enough and want to cause > > even more chaos. > > Do you realize that sentence accuses Michael, Muhammad and me of > pursuing a personal power trip instead of seeking the good of the > project? Do you realize how incredibly insulting you are? > > Regards, > > -- > Nicolas George > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > No, I was referring to you and you alone. You've been more insulting towards the people who do hard work and submit patches by going out of your way to block them and saying "The burden of proof is on you!". And by saying this you're basically not even wanting to review anything - you'd rather be spoonfed some facts than look at the code, figure out what it does, what it changes and seeing whether it's doing what its meant to do or not. If you want to be taken seriously and not be seen as someone as insulting as you think I was here then you should provide constructive criticism, use quotes, provide some information where you think there's an issue and finally propose an alternative. So far you've only done "I don't like this API and I can't be convinced otherwise!" and act surprised when your rhetoric to revert everything was criticized. Meanwhile mfcc64 provided all I just said and michaelni provided objective testing, so don't even compare yourself to them. Instead, why don't you send a patch or even a WIP of what you think ought to be done to the API? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cmdutils: fix printing of codecs
Rostislav Pehlivanov (2018-02-08): > We should fix what we have right now. The API looks good too except some > people here feel like they haven't bikeshedded enough and want to cause > even more chaos. Do you realize that sentence accuses Michael, Muhammad and me of pursuing a personal power trip instead of seeking the good of the project? Do you realize how incredibly insulting you are? Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cmdutils: fix printing of codecs
On 8 February 2018 at 10:06, Nicolas George wrote: > Michael Niedermayer (2018-02-08): > > +1 > > I agree too. > > And maybe, since we are reverting something, revert the whole series. > > Regards, > > -- > Nicolas George > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > -1, I object to reverting anything. We should fix what we have right now. The API looks good too except some people here feel like they haven't bikeshedded enough and want to cause even more chaos. One bad commit and you all go screaming revert with your pitchforks instead of trying to fix it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cmdutils: fix printing of codecs
On 8 February 2018 at 01:08, Muhammad Faiz wrote: > On Thu, Feb 8, 2018 at 7:35 AM, James Almer wrote: > > On 2/7/2018 9:32 PM, Michael Niedermayer wrote: > >> On Wed, Feb 07, 2018 at 09:07:39PM +, Josh de Kock wrote: > >>> Yes, my bad. It looked like it worked initially (was more > >>> worried about getting a fix out quickly), but it didnt. Try this one. > >>> > >>> --- > >>> fftools/cmdutils.c | 104 +- > --- > >>> 1 file changed, 58 insertions(+), 46 deletions(-) > >> > >> I dont know if this is supposed to fix the other lists > >> but > >> ./ffmpeg -demuxers > >> still returns nonsense with this patch > >> > >> File formats: > >> D. = Demuxing supported > >> .E = Muxing supported > >> -- > >> E 3dostr 3DO STR > >> E 4xm 4X Technologies > >> ... > >> a while ago this was returned: > >> > >> File formats: > >> D. = Demuxing supported > >> .E = Muxing supported > >> -- > >> D 3dostr 3DO STR > >> D 4xm 4X Technologies > > > > Perhaps cdc78058c78dfa4966758a342acd2c1f3b282c46 should be reverted > > then. If the new API may actually get changed in the coming days once > > some consensus is reached then there's no point trying to get this > > working with things as is. > > +1. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > -1, there's no point in reverting this and then arguing for 3 weeks with people who will never use the API in the first place, don't understand the problem this patchset solved and just want to see their way be the only way things are done. We should fix this patch, fix another one if there's any and it'll be fine. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cmdutils: fix printing of codecs
Michael Niedermayer (2018-02-08): > +1 I agree too. And maybe, since we are reverting something, revert the whole series. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cmdutils: fix printing of codecs
On Wed, Feb 07, 2018 at 09:35:24PM -0300, James Almer wrote: > On 2/7/2018 9:32 PM, Michael Niedermayer wrote: > > On Wed, Feb 07, 2018 at 09:07:39PM +, Josh de Kock wrote: > >> Yes, my bad. It looked like it worked initially (was more > >> worried about getting a fix out quickly), but it didnt. Try this one. > >> > >> --- > >> fftools/cmdutils.c | 104 > >> + > >> 1 file changed, 58 insertions(+), 46 deletions(-) > > > > I dont know if this is supposed to fix the other lists > > but > > ./ffmpeg -demuxers > > still returns nonsense with this patch > > > > File formats: > > D. = Demuxing supported > > .E = Muxing supported > > -- > > E 3dostr 3DO STR > > E 4xm 4X Technologies > > ... > > a while ago this was returned: > > > > File formats: > > D. = Demuxing supported > > .E = Muxing supported > > -- > > D 3dostr 3DO STR > > D 4xm 4X Technologies > > Perhaps cdc78058c78dfa4966758a342acd2c1f3b282c46 should be reverted > then. If the new API may actually get changed in the coming days once > some consensus is reached then there's no point trying to get this > working with things as is. +1 this seems to fix the 2 issues iam still looking into a 4th issue ive seen (not bisected yet, so may be from something unrelated) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cmdutils: fix printing of codecs
On Thu, Feb 8, 2018 at 7:35 AM, James Almer wrote: > On 2/7/2018 9:32 PM, Michael Niedermayer wrote: >> On Wed, Feb 07, 2018 at 09:07:39PM +, Josh de Kock wrote: >>> Yes, my bad. It looked like it worked initially (was more >>> worried about getting a fix out quickly), but it didnt. Try this one. >>> >>> --- >>> fftools/cmdutils.c | 104 >>> + >>> 1 file changed, 58 insertions(+), 46 deletions(-) >> >> I dont know if this is supposed to fix the other lists >> but >> ./ffmpeg -demuxers >> still returns nonsense with this patch >> >> File formats: >> D. = Demuxing supported >> .E = Muxing supported >> -- >> E 3dostr 3DO STR >> E 4xm 4X Technologies >> ... >> a while ago this was returned: >> >> File formats: >> D. = Demuxing supported >> .E = Muxing supported >> -- >> D 3dostr 3DO STR >> D 4xm 4X Technologies > > Perhaps cdc78058c78dfa4966758a342acd2c1f3b282c46 should be reverted > then. If the new API may actually get changed in the coming days once > some consensus is reached then there's no point trying to get this > working with things as is. +1. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cmdutils: fix printing of codecs
On Wed, Feb 07, 2018 at 09:07:39PM +, Josh de Kock wrote: > Yes, my bad. It looked like it worked initially (was more > worried about getting a fix out quickly), but it didnt. Try this one. > > --- > fftools/cmdutils.c | 104 > + > 1 file changed, 58 insertions(+), 46 deletions(-) The output of this differs from before it now lists decoders and encoders even if theres just one with matching name to the codec a bugfix should not introduce such a change - D.VI.S 012v Uncompressed 4:2:2 10-bit - D.V.L. 4xm 4X Movie - D.VI.S 8bps QuickTime 8BPS video + D.VI.S 012v Uncompressed 4:2:2 10-bit (decoders: 012v ) + D.V.L. 4xm 4X Movie (decoders: 4xm ) + D.VI.S 8bps QuickTime 8BPS video (decoders: 8bps ) .EVIL. a64_multiMulticolor charset for Commodore 64 (encoders: a64multi ) .EVIL. a64_multi5 Multicolor charset for Commodore 64, extended with 5th color (colram) (encoders: a64multi5 ) - D.V..S aasc Autodesk RLE - D.VIL. aic Apple Intermediate Codec - DEVI.S alias_pixAlias/Wavefront PIX image - DEVIL. amv AMV Video - D.V.L. anm Deluxe Paint Animation - D.V.L. ansi ASCII/ANSI art - DEV..S apng APNG (Animated Portable Network Graphics) image - DEVIL. asv1 ASUS V1 - DEVIL. asv2 ASUS V2 - D.VIL. aura Auravision AURA - D.VIL. aura2Auravision Aura 2 + D.V..S aasc Autodesk RLE (decoders: aasc ) + D.VIL. aic Apple Intermediate Codec (decoders: aic ) + DEVI.S alias_pixAlias/Wavefront PIX image (decoders: alias_pix ) (encoders: alias_pix ) + DEVIL. amv AMV Video (decoders: amv ) (encoders: amv ) + D.V.L. anm Deluxe Paint Animation (decoders: anm ) + D.V.L. ansi ASCII/ANSI art (decoders: ansi ) + DEV..S apng APNG (Animated Portable Network Graphics) image (decoders: apng ) (encoders: apng ) + DEVIL. asv1 ASUS V1 (decoders: asv1 ) (encoders: asv1 ) + DEVIL. asv2 ASUS V2 (decoders: asv2 ) (encoders: asv2 ) + D.VIL. aura Auravision AURA (decoders: aura ) + D.VIL. aura2Auravision Aura 2 (decoders: aura2 ) ..V.L. av1 Alliance for Open Media AV1 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cmdutils: fix printing of codecs
On 2/7/2018 9:32 PM, Michael Niedermayer wrote: > On Wed, Feb 07, 2018 at 09:07:39PM +, Josh de Kock wrote: >> Yes, my bad. It looked like it worked initially (was more >> worried about getting a fix out quickly), but it didnt. Try this one. >> >> --- >> fftools/cmdutils.c | 104 >> + >> 1 file changed, 58 insertions(+), 46 deletions(-) > > I dont know if this is supposed to fix the other lists > but > ./ffmpeg -demuxers > still returns nonsense with this patch > > File formats: > D. = Demuxing supported > .E = Muxing supported > -- > E 3dostr 3DO STR > E 4xm 4X Technologies > ... > a while ago this was returned: > > File formats: > D. = Demuxing supported > .E = Muxing supported > -- > D 3dostr 3DO STR > D 4xm 4X Technologies Perhaps cdc78058c78dfa4966758a342acd2c1f3b282c46 should be reverted then. If the new API may actually get changed in the coming days once some consensus is reached then there's no point trying to get this working with things as is. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cmdutils: fix printing of codecs
On Wed, Feb 07, 2018 at 09:07:39PM +, Josh de Kock wrote: > Yes, my bad. It looked like it worked initially (was more > worried about getting a fix out quickly), but it didnt. Try this one. > > --- > fftools/cmdutils.c | 104 > + > 1 file changed, 58 insertions(+), 46 deletions(-) I dont know if this is supposed to fix the other lists but ./ffmpeg -demuxers still returns nonsense with this patch File formats: D. = Demuxing supported .E = Muxing supported -- E 3dostr 3DO STR E 4xm 4X Technologies ... a while ago this was returned: File formats: D. = Demuxing supported .E = Muxing supported -- D 3dostr 3DO STR D 4xm 4X Technologies [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
