[FFmpeg-devel] [PATCH]opencl: compile kernels separately

Stefano Sabatini stefasab at gmail.com
Wed Oct 30 15:29:40 CET 2013


On date Wednesday 2013-10-30 12:01:57 +0100, Michael Niedermayer encoded:
> On Wed, Oct 30, 2013 at 11:07:20AM +0800, Wei Gao wrote:
[...]
> i suggest to split the patch into a libavutil and a libavfilter
> one. This reduces the chances of breaking public API/ABI as the
> code must still build (and work) with only the libavutil patch applied.
> 
> also i suggest to make sure that your new API will serve future needs
> and be easy extendible not requiring major version bumps for changes.
> Its likely alot less work to
> design it well in the first place than to deal with these API/ABI
> compatibility issues later.
> 
> old functions that are not part of the new API should be marked as
> deprecated, point the reader to the new and be put under #if so they
> get automatically disabled with the next major version bump.
> 
> also if the new is still meant to be experimental, it might be best
> to require a --enable-experimental in configure.
> In that case then, random ABI/API changes would be no problem, sadly
> its too late for that for the old API, but it could be used for the
> new ...
> 
> also, if its too hard to support old and new at the same time, one
> "hack" would be to support enough of the old API/ABI so building
> succeeds and code trying to use it gets a clear & clean error
> like return AVERROR(ENOSYS) on old functions.

While I agree on --enable-experimental, this should not disallow to
break this API now, since it was agreed that it could be marked as
experimental one year ago.
-- 
FFmpeg = Frenzy Fostering Multimedia Picky Emblematic Ghost


More information about the ffmpeg-devel mailing list