On date Tuesday 2012-10-23 14:45:53 -0600, Michael Bradshaw encoded: > On Tue, Oct 23, 2012 at 2:38 PM, Stefano Sabatini <[email protected]> wrote: > > On date Tuesday 2012-10-23 13:03:27 -0600, Michael Bradshaw encoded: > >> I'm using avfilter to rescale video (and convert it to the right pixel > >> format) and convert audio (to the right sample format, sample rate, > >> and channel_layout) (I'm also buffering audio using asetnsamples to > >> fill frames with a consistent number of samples). While reading the > >> source video and source audio, it's possible they change in the > >> stream. > > > >> If the source audio stream changes (i.e. sample rate, sample > >> format, channel_layout), or if the source video stream changes (width, > >> height, or pixel format), do I have to completely destroy and rebuild > >> the filter graph? Or is there a way to "update" the source filters to > >> the new formats and update (without destroying) the filter graph? > > > > Some filters do, others won't, so in general the best way is to > > "normalize" the input media before injecting it in the filtergraph, a > > consistent and robust way to deal with that will require some > > (re)design at the framework level. >
> How would you suggest to "normalize" the input media? Because that's > exactly what I'm (ab)using libavfilter for: given "unormalized" source > media, produce "normalized" output with consistent picture size/format > and audio format. If there's currently a preferred or better solution > to do this, I'd love to know. Well, do you need to normalize the input or the output? Old versions of buffer/abuffer supported input normalization, before the libav changes discarding that feature were merged in. In general it should not be hard to implement a normalization input buffer source. Dealing with that in a generic way (some filters can support mid-stream changes, other can't, so the framework should automatically auto-add format normalizers in the latter case). Alternatively you could just have a scaler/resampler just before the filtergraph input, if you need to perform further filtering. > Right now I'm thinking of abandoning libavfilter and just using > swscale and swresample directly, and dynamically reconfiguring the > swscale and swresample contexts as necessary, but I'm exploring > alternatives. > > >> My primary concern is that asetnsamples may have some samples > >> buffered, and destroying and recreating the filter graph would lose > >> these buffered samples. > >> > > > >> Also, if it's possible to update the filters without destroying the > >> graph and recreating it, would it be possible to change the number of > >> samples set for asetnsamples? I'm not seeing anything that makes it > >> look like this is possible, but it's worth double checking. > > > > This should be easily feasible by implementing a process_command() > > callback in asetnsamples, also have a look at the asendcmd filter, > > patches (or alternatively a feature request) are welcome. > > Cool. I guess this can be added to the "On libavfilter: A summary of > issues" thread. I'll work on it if I have time, though I doubt I will > for a while. Well libavfilter dynamic reconfiguration can be considered a framework limitation (and I don't think there are many filtering frameworks which can deal with it), the lack of contributions or lack of time of the FFmpeg slav^H^H^H^Hdevelopers is hardly a problem specific of libavfilter. _______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
