On Mon, Jun 6, 2016 at 9:01 AM, Hendrik Leppkes <h.lepp...@gmail.com> wrote:
> On Sun, Jun 5, 2016 at 5:13 AM, Michael Niedermayer
> <mich...@niedermayer.cc> wrote:
>> This fixes a API regression
>> Probably fixes Ticket5451
>>
>> Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc>
>> ---
>> libavformat/utils.c | 4 ++--
>> libavformat/version.h | 2 +-
>> 2 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavformat/utils.c b/libavformat/utils.c
>> index ac056c4..7ca0a12 100644
>> --- a/libavformat/utils.c
>> +++ b/libavformat/utils.c
>> @@ -3789,8 +3789,6 @@ FF_DISABLE_DEPRECATION_WARNINGS
>> av_codec_set_lowres(st->codec,
>> av_codec_get_lowres(st->internal->avctx));
>> st->codec->width = st->internal->avctx->width;
>> st->codec->height = st->internal->avctx->height;
>> - st->codec->coded_width = st->internal->avctx->coded_width;
>> - st->codec->coded_height = st->internal->avctx->coded_height;
>> }
>>
>> if (st->codec->codec_tag != MKTAG('t','m','c','d'))
>> @@ -3807,6 +3805,8 @@ FF_DISABLE_DEPRECATION_WARNINGS
>> }
>>
>> // Fields unavailable in AVCodecParameters
>> + st->codec->coded_width = st->internal->avctx->coded_width;
>> + st->codec->coded_height = st->internal->avctx->coded_height;
>> st->codec->properties = st->internal->avctx->properties;
>> FF_ENABLE_DEPRECATION_WARNINGS
>> #endif
>> diff --git a/libavformat/version.h b/libavformat/version.h
>> index c92a23f..2f79b7f 100644
>> --- a/libavformat/version.h
>> +++ b/libavformat/version.h
>> @@ -29,7 +29,7 @@
>>
>> #include "libavutil/version.h"
>>
>> -// When bumping major check Ticket5467, 5421 for regressing
>> +// When bumping major check Ticket5467, 5421, 5451 for regressing
>> // Also please add any ticket numbers that you belive might regress here
>> #define LIBAVFORMAT_VERSION_MAJOR 57
>> #define LIBAVFORMAT_VERSION_MINOR 37
>> --
>> 1.7.9.5
>
> The ticket in question accesses st->codec to get this field. st->codec
> is going away, so there is no point in testing this "regression",
> since they need to update their API usage first for it to even
> compile.
> Heck the same thing applies to the other tickets you listed here, all
> of those access information from st->codec which is going away
> entirely, so you can't really "test" these cases. Someone would have
> to update the code to use codecpar first, and while doing this
> migration they would need to preserve whatever behavior exists today.
>
What I forgot to write, patch is otherwise fine, exporting information
into st->codec that was previously available to avoid regressions for
people that still use st->codec is OK.
- Hendrik
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
