[FFmpeg-devel] [RFC] The Big Bump
Fri Feb 4 01:51:21 CET 2011
Alexander Strange <astrange at ithinksw.com> writes:
> On Feb 3, 2011, at 3:24 PM, Jason Garrett-Glaser wrote:
>> We should definitely remove all codec-specific options in
>> AVCodecContext. We should also reorder the options to work with
>> ffmpeg-mt, like x264 does -- so that copying a codec state to a thread
>> can be done with a memcpy instead of explicitly copying every option.
>> That is, make a section of the struct for things that need to be
> I want to do this, but it'd be a large API change, and one that
> doesn't have any deprecation notices on it already. I think removing
> many more fields might have to wait for major bump+1, which should
> come sooner.
What strategy do you suggest for getting rid of this cruft in less
than another 3 years without upsetting too many users?
> Notes scanning avcodec.h top to bottom:
> - ME_LOG, ME_PHODS are unused in code. ME_X1 is nearly unused.
They are used in the libxvid wrapper, but it would be better off with
dedicated private options anyhow.
> - CODEC_FLAG2_BPYRAMID .. CODEC_FLAG2_AUD and a few more are x264 only.
> Many of the rest are mpegvideo encoding only.
> - reordered_opaque can go
What else does the same thing?
> - 'delay' and 'has_b_frames' duplicate each other
> - rc_strategy says "FIXME remove"
> - b_frame_strategy has an x264-specific definition
> - mv_bits ... misc_bits look internal to ratecontrol
> - 'slice_count' and 'slices' duplicate each other
> - bits_per_coded_sample and bits_per_raw_sample are related, but far
> apart in the struct
> - it would be nice if coded_frame went away
The only thing I've ever used it for was a makeshift workaround for
lack of proper timestamp tracking, which we now have.
> - mb_decision (or at least FF_MB_DECISION_BITS) is obsolete
> - crf ... directpred, weighted_p_pred ... crf_max are x264 only
> - reordered_opaque can go from AVCodecContext too
I still disagree on that one.
> - I can't remember why subtitle_header and extradata are different
> There's also a lot of mpegvideo encode-only fields, which I'm
> tempted to suggest could go into codec-specific options. This would
> only make MpegEncContext bigger.
mans at mansr.com
More information about the ffmpeg-devel