[FFmpeg-devel] [RFC] The Big Bump

[Alexander Strange]

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 thread-synced.
> 
> Jason

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.

Notes scanning avcodec.h top to bottom:

- ME_LOG, ME_PHODS are unused in code. ME_X1 is nearly unused. 

- 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

- '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

- 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 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.