[FFmpeg-devel] [PATCH] cmdutils: fix printing of codecs

[Rostislav Pehlivanov]

On 8 February 2018 at 13:19, James Almer <jamrial at gmail.com> wrote:

> On 2/8/2018 9:52 AM, wm4 wrote:
> > On Thu, 8 Feb 2018 10:29:11 +0000
> > Rostislav Pehlivanov <atomnuker at gmail.com> wrote:
> >
> >> On 8 February 2018 at 01:08, Muhammad Faiz <mfcc64 at gmail.com> wrote:
> >>
> >>> On Thu, Feb 8, 2018 at 7:35 AM, James Almer <jamrial at 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 at 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 at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>