On Sat, 23 Nov 2013, [email protected] wrote:
The problems with it are rather obvious: - it uses raw data buffers instead of AVPackets - is completely undocumented - the filtering function takes a very questionable set of parameters: * a codec context (not clear from where it's supposed to come from), unspecified stuff is done on it * an opaque 'args' string * 'keyframe' (wtf?)I've drafted a new API, attached below. The basic usage is something like: av_bsf_alloc(); set options through AVOptions send packets in with av_bsf_add_packet() get (in general a different number of) packets out with av_bsf_get_packet() av_bsf_free(); some notes: - at this stage, if the caller has multiple filters in chain, he has to manage them himself. I considered wrapping them in something similar to AVFilterGraph in lavfi, but then decided against it because there's a high risk of adding something that's either not sufficiently general or too overdesigned. We have too few bitstream filters currently and almost none of them make sense in a chain, so I'd postpone a higher-level filter-chain API until it's actually needed and we have a better idea what features it should have. Then we should be able to just extend the API without breaking any existing callers.
I agree that making some bitstream filter chain API would be overkill, especially at this point.
- I'm quite sure we _don't_ want the filter to get an external codec context of any kind and mess with it. Currently existing filters mainly use the codec context for extradata (both reading and writing). For writing, we can use the NEW_EXTRADATA packet side data, though this probably means we'll have to teach more muxers to deal with this side data. I see a larger problem in reading extradata -- one idea is to make lavc encoding and lavf demuxing to set the NEW_EXTRADATA side data on the first packet. Other/better ideas welcome.
Hmm. Extending the use of the NEW_EXTRADATA side data could in itself probably be useful - I don't think we even support it in muxers that could simply do that right now (e.g. flv).
But for passing in the existing extradata that way does sound a little contrieved - although I'm not sure the alternatives are any better either.
The problem with NEW_EXTRADATA in general is that it's a bit too complicated for the normal simple cases with one constant piece of extradata for the whole stream, where the normal flow of just storing it in some context is simple and straightforward enough. If there is extradata present at startup and the filter changes it (or passes it through) it would be available somewhere. But hooking this up between lavf and the normal lavc codecs would sound like a bit too much extra manual code.
Further questions - is extradata the only thing that is written in AVCodecContext by the bitstream filters today? Just so that we don't design a replacement that isn't usable for the bitstream filters that exist even today.
- reconfiguration - do we want an open/close pattern to change options at runtime? Or do we want the caller to be able to av_opt_set() at any point and the filter has to detect that? Or another insane way is to send updated options in a dict in side data of the input packets. Again, better ideas welcome
Hmm, I don't use bitstream filters enough myself to have a good opinion on this. For private options in lavf, this is mostly handled on a an option-by-option basis - some options that it makes sense to update are checked each time by the muxers/protocols, while most aren't checked.
// Martin _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
