[FFmpeg-devel] [RFC] The Big Bump

[Måns Rullgård]

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

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.

-- 
M?ns Rullg?rd
mans at mansr.com