On 04/18/2011 06:23 PM, Johan Andersson wrote: > On Mon, Apr 18, 2011 at 06:20:17PM -0400, Alexander Strange wrote: >> >> On Apr 18, 2011, at 3:03 AM, Anton Khirnov wrote: >> >>> --- >>> libavcodec/avcodec.h | 19 ------------------- >>> libavcodec/utils.c | 16 ---------------- >>> libavcodec/version.h | 3 --- >>> 3 files changed, 0 insertions(+), 38 deletions(-) >>> >>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h >>> index cf3664a..78dd208 100644 >>> --- a/libavcodec/avcodec.h >>> +++ b/libavcodec/avcodec.h >>> @@ -3741,25 +3741,6 @@ int avcodec_decode_audio3(AVCodecContext *avctx, >>> int16_t *samples, >>> int *frame_size_ptr, >>> AVPacket *avpkt); >>> >>> -#if FF_API_VIDEO_OLD >>> -/** >>> - * Decode a video frame from buf into picture. >>> - * Wrapper function which calls avcodec_decode_video2. >>> - * >>> - * @deprecated Use avcodec_decode_video2 instead. >>> - * @param avctx the codec context >>> - * @param[out] picture The AVFrame in which the decoded video frame will >>> be stored. >>> - * @param[in] buf the input buffer >>> - * @param[in] buf_size the size of the input buffer in bytes >>> - * @param[in,out] got_picture_ptr Zero if no frame could be decompressed, >>> otherwise, it is nonzero. >>> - * @return On error a negative value is returned, otherwise the number of >>> bytes >>> - * used or zero if no frame could be decompressed. >>> - */ >>> -attribute_deprecated int avcodec_decode_video(AVCodecContext *avctx, >>> AVFrame *picture, >>> - int *got_picture_ptr, >>> - const uint8_t *buf, int buf_size); >>> -#endif >>> - >> >> It feels strange to have the remaining public API called decode_video2 >> instead of renaming it to decode_video. I guess that would annoy people, >> though. >> > > maybe change that with the big bump? >
If I may, you will annoy people considerably more if you diverge the API such that ffmpeg vs. libav is a port, requiring a decision to support or not, rather than a drop in replacement. This seems like it would be a step along the road to not being a viable path forward for media players and distros. Maybe keep the old name around for a while as a synonym. I know that feels ugly, but it is necessary. Personally I have cut over to libav and mplayer2. I am heartened by the energy I see being put into cleanup and improvement, but I encourage you to keep your API consumers uppermost in your mind. _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel