[FFmpeg-devel] [PATCH] lavfi: add asendcmd and sendcmd filters

[Clément Bœsch]

On Mon, Sep 03, 2012 at 04:04:30PM +0200, Stefano Sabatini wrote:
> On date Monday 2012-09-03 13:32:04 +0200, Clément Bœsch encoded:
> > On Mon, Sep 03, 2012 at 12:28:11PM +0200, Stefano Sabatini wrote:
> > [...]
> > > > Even if "filter class" and "specific filter instance" sounds more correct
> > > > from a developer perspective, would it make more sense to say that it's
> > > > just the filter name?
> > > > 
> > > 
> > > > And by the way, how do you identify the different target instances of the
> > > > same filter? ("volume", "volume1", "volume2", ...?)
> > > 
> > > Different filters have different instance name (parsed_...), it is not
> > > still possible to specify the name of an instance in the filter graph.
> > > 
> > > > > + at var{time} specify the time when the filter command is sent, expressed
> > > > > +as a time duration.
> > > > > +
> > > > 
> > > > Note: as I said on IRC, I really think this should allow frame accurate
> > > > timing range at some point.
> > > 
> > > Mixing times and frames is really hard if not impossible.
> > >  
> > 
> > :(
> 
> When I was working on an extended fade filter I tried to mix frame
> count and time interval, and it was a mess. For example:
> #100-100
> 
> depending on the timestamps the interval could be negative (end <
> start). I also tried to handle special interval like:
> 10+#100
> 
> (starting from 10 and continuing for 100 frames).
> 
> Dealing with frame-count interval e.g. #100-#200 should be feasible,
> but again that won't work with seeking, since the frame counter will
> always increase.
> 

Well OK, mixing both might be a problem (and I don't think users need
that), but allowing timestamp-only or frame-only should be possible,
right?

[...]

-- 
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120903/2e63963a/attachment.asc>