On 8 February 2018 at 13:19, James Almer <jamr...@gmail.com> wrote: > On 2/8/2018 9:52 AM, wm4 wrote: > > On Thu, 8 Feb 2018 10:29:11 +0000 > > Rostislav Pehlivanov <atomnu...@gmail.com> wrote: > > > >> On 8 February 2018 at 01:08, Muhammad Faiz <mfc...@gmail.com> wrote: > >> > >>> On Thu, Feb 8, 2018 at 7:35 AM, James Almer <jamr...@gmail.com> wrote: > >>>> On 2/7/2018 9:32 PM, Michael Niedermayer wrote: > >>>>> On Wed, Feb 07, 2018 at 09:07:39PM +0000, 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
