[FFmpeg-devel] [RFC] The Big Bump
Fri Feb 4 01:24:54 CET 2011
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.
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.
More information about the ffmpeg-devel