[FFmpeg-devel] [PATCH 2/2] avcodec: mark AV_CODEC_CAP_SUBFRAMES as deprecated

[wm4]

On Sun, 31 Dec 2017 13:23:44 +0000
Rostislav Pehlivanov <atomnuker at gmail.com> wrote:

> On 31 December 2017 at 13:13, wm4 <nfxjfg at googlemail.com> wrote:
> 
> > On Sun, 31 Dec 2017 13:07:28 +0000
> > Rostislav Pehlivanov <atomnuker at gmail.com> wrote:
> >  
> > > The new decoding API supports 1 avpkt -> multiple avframes natively.
> > >
> > > Signed-off-by: Rostislav Pehlivanov <atomnuker at gmail.com>
> > > ---
> > >  libavcodec/avcodec.h | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> > > index 5a27211b80..7e74c3b01c 100644
> > > --- a/libavcodec/avcodec.h
> > > +++ b/libavcodec/avcodec.h
> > > @@ -985,6 +985,7 @@ typedef struct RcOverride{
> > >   */
> > >  #define AV_CODEC_CAP_SMALL_LAST_FRAME    (1 <<  6)
> > >
> > > +#if FF_API_OLD_CODING
> > >  /**
> > >   * Codec can output multiple frames per AVPacket
> > >   * Normally demuxers return one frame at a time, demuxers which do not  
> > do  
> > > @@ -995,8 +996,10 @@ typedef struct RcOverride{
> > >   * may return multiple frames in a packet. This has many disadvantages  
> > like  
> > >   * prohibiting stream copy in many cases thus it should only be  
> > considered  
> > >   * as a last resort.
> > > + * @deprecated the new decoding API handles this natively
> > >   */
> > >  #define AV_CODEC_CAP_SUBFRAMES           (1 <<  8)
> > > +#endif
> > >  /**
> > >   * Codec is experimental and is thus avoided in favor of non  
> > experimental  
> > >   * encoders  
> >
> > That is completely orthogonal. The old API didn't require checking this
> > either. (And some codecs are incorrectly marked anyway.)
> > _______________________________________________
> > ffmpeg-devel mailing list
> > ffmpeg-devel at ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >  
> 
> Either way, we should deprecate this so its removed at the same time as the
> old api.
> The incorrectly marked codecs will be fixed when we port all decoders and
> encoders to the new api.

I don't mind. The CAP never made too much sense to me anyway. You
should probably still update the commit message - the old decoding API
could do this too, just in a more awkward way.