On Tue, 19 Mar 2013 08:41:01 -0400, Keith Lawson <[email protected]> wrote: > > > On 17.03.2013 13:27, Anton Khirnov wrote: > > > > Hmm..just realized that this isn't going to work so easily. > > The problem is that the select filter doesn't know that there won't > > ever be any > > more frames while will be let through, so it doesn't signal end of > > stream to the > > overlay's second input. So overlay keeps waiting for new frames on > > its second > > input while more and more frames get queued on its main input. > > > > Would that be the cause of my memory issues then? >
Yes. > > So for this arrangement to work there needs to be some way to signal > > end of > > stream on the secondary input. > > I'm considering either an option to the select filter, or perhaps a > > new 'trim' > > filter would be better. > > I was contemplating adding a time range to the delogo filter but if a > new 'trim' filter is more appropriate I'd be happy to start the work on > that based on the 'select' filter. Which way would be the most > appropriate way to implement this functionality? > I think it's better not to bloat existing filters with too many options, so yes -- a new filter is probably better. I imagine it can take as options start/end values for one of - number of frames - time in seconds - timestamp in the timebase units and then a simple check in filter_frame() whether those value are before start => drop, between start and end => pass, after end => drop + return EOF If you're going to take vf_select as the base, note that it's one of the filters that still use their own custom options parsing which we are trying to replace with a standard AVOption system. See the branch 'lavfi' in my tree at git://git.khirnov.net/libav which has all the filters converted to AVOptions. Also feel free to ask questions in our IRC channel if anything is unclear. -- Anton Khirnov _______________________________________________ libav-tools mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-tools
