On Thu, 21 Apr 2016 04:41:44 +0200
Michael Niedermayer <mich...@niedermayer.cc> wrote:
> On Wed, Apr 20, 2016 at 08:18:54PM +0200, wm4 wrote:
> > On Wed, 20 Apr 2016 15:05:40 -0300
> > James Almer <jamr...@gmail.com> wrote:
> >
> > > On 4/20/2016 2:49 PM, Michael Niedermayer wrote:
> > > > With this the use of the caps_internal from libavormat can be avoided
> > > >
> > > > TODO: bump version
> > > >
> > > > Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc>
> > > > ---
> > > > libavcodec/internal.h | 2 ++
> > > > libavcodec/utils.c | 4 ++++
> > > > 2 files changed, 6 insertions(+)
> > > >
> > > > diff --git a/libavcodec/internal.h b/libavcodec/internal.h
> > > > index 24d320c..6c0efec 100644
> > > > --- a/libavcodec/internal.h
> > > > +++ b/libavcodec/internal.h
> > > > @@ -293,6 +293,8 @@ const uint8_t *avpriv_find_start_code(const uint8_t
> > > > *p,
> > > > const uint8_t *end,
> > > > uint32_t *state);
> > > >
> > > > +int avpriv_codec_get_cap_skip_frame_fill_param(const AVCodec *codec);
> > > > +
> > > > /**
> > > > * Check that the provided frame dimensions are valid and set them on
> > > > the codec
> > > > * context.
> > > > diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> > > > index 44843a4..9766bb0 100644
> > > > --- a/libavcodec/utils.c
> > > > +++ b/libavcodec/utils.c
> > > > @@ -1160,6 +1160,10 @@ int av_codec_get_max_lowres(const AVCodec *codec)
> > > > return codec->max_lowres;
> > > > }
> > > >
> > > > +int avpriv_codec_get_cap_skip_frame_fill_param(const AVCodec *codec){
> > > > + return !!(codec->caps_internal &
> > > > FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM);
> > > > +}
> > >
> > > Might as well do a generic accessor function like "int
> > > avpriv_codec_get_caps(const AVCodec *codec)"
> > > or "int avpriv_codec_check_cap(const AVCodec *codec, int cap)" if this
> > > field is going to be used
> > > outside lavc.
> > > If for whatever reason any of the other flags need to be checked in lavf,
> > > you'll not need to
> > > introduce another avpriv function.
> >
> > IMHO the idea should be that another of such a case shouldn't happen.
> > The case which this patch tries to fix was introduced accidentally
> > (and also, it really should have been implemented as a parser).
> >
> > I still wonder if this could be fixed in a better way.
>
> should i wait with the patch or apply it ?
>
> [...]
Doesn't look like anyone has a better idea, so OK from me.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
