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.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
