On Tue, 16 Jun 2015 21:55:13 +0200
Hendrik Leppkes <h.lepp...@gmail.com> wrote:
> On Tue, Jun 16, 2015 at 9:45 PM, wm4 <nfx...@googlemail.com> wrote:
> > On Tue, 16 Jun 2015 21:31:26 +0200
> > Hendrik Leppkes <h.lepp...@gmail.com> wrote:
> >
> >> On Tue, Jun 16, 2015 at 9:23 PM, wm4 <nfx...@googlemail.com> wrote:
> >> > On Tue, 16 Jun 2015 21:18:13 +0200
> >> > Hendrik Leppkes <h.lepp...@gmail.com> wrote:
> >> >
> >> >> On Tue, Jun 16, 2015 at 8:33 PM, wm4 <nfx...@googlemail.com> wrote:
> >> >> > On Tue, 16 Jun 2015 13:29:55 +0000
> >> >> > Paul B Mahol <one...@gmail.com> wrote:
> >> >> >
> >> >> >> Also fixes clash with smv audio codec.
> >> >> >>
> >> >> >> Signed-off-by: Paul B Mahol <one...@gmail.com>
> >> >> >> ---
> >> >> >> libavcodec/codec_desc.c | 2 +-
> >> >> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >> >> >>
> >> >> >> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> >> >> >> index c1694f3..f32843a 100644
> >> >> >> --- a/libavcodec/codec_desc.c
> >> >> >> +++ b/libavcodec/codec_desc.c
> >> >> >> @@ -1178,7 +1178,7 @@ static const AVCodecDescriptor
> >> >> >> codec_descriptors[] = {
> >> >> >> {
> >> >> >> .id = AV_CODEC_ID_SMVJPEG,
> >> >> >> .type = AVMEDIA_TYPE_VIDEO,
> >> >> >> - .name = "smv",
> >> >> >> + .name = "smvjpeg",
> >> >> >> .long_name = NULL_IF_CONFIG_SMALL("Sigmatel Motion Video"),
> >> >> >> },
> >> >> >>
> >> >> >
> >> >> > An incompatible API change should come with a major bump.
> >> >> >
> >> >>
> >> >> Strings in the codec descriptor are API now?
> >> >
> >> > Of course. Just like AVOptions, filter names, etc.
> >> >
> >> > (The patch was pushed anyway. Who needs reviews. Or stable APIs.)
> >>
> >> If you want to go down that route, you could argue that any return
> >> value from any function is part of the API, and if it changes, it
> >> needs a major bump.
> >> .. and that would mean you cannot change anything ever at all.
> >>
> >> I see no reason these strings should be considered API. They are
> >> descriptive names, not option tokens or anything.
> >> If you want a reliable static way to identify a codec, use the id.
> >
> > Using strings for codec IDs is pretty flexible and convenient, and I
> > don't want to give up on it. But more importantly, these are being used
> > by many scripts and user interfaces which make use of libavcodec. Can
> > you imagine the chaos if you renamed the "h264" codec to "avc"? Do you
> > suppose applications should have their own lookup tables for
> > AV_CODEC_IDs? They'd have to update it all the time. And it wouldn't
> > work for scripts using ffmpeg.c (which makes ffmpeg.c an API user
> > relying on codec strings not changing randomly).
> >
>
> But this is not the name of the decoder that was changed, which I
> would agree would be bad, since you can use it to select the decoder
> you want, but the codec descriptor.
Well, "libx264" (and "libx264rgb") is the name of the encoder, while
"h264" is the name of the codec (dictated by the codec descriptor). I
claim you can't rename either without breaking users.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
