On Mon, Jun 06, 2016 at 09:02:34AM +0200, Hendrik Leppkes wrote:
> 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.patch applied with some rewording i will post a patch with unrelated to this ticket rewording of the note about bumps [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you drop bombs on a foreign country and kill a hundred thousand innocent people, expect your government to call the consequence "unprovoked inhuman terrorist attacks" and use it to justify dropping more bombs and killing more people. The technology changed, the idea is old.
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
