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