[FFmpeg-devel] [PATCH] lavfi: add asendcmd and sendcmd filters
ubitux at gmail.com
Tue Sep 11 21:40:48 CEST 2012
On Tue, Sep 11, 2012 at 09:26:56PM +0200, Nicolas George wrote:
> Le sextidi 26 fructidor, an CCXX, Clément Bœsch a écrit :
> > If you are working on editing, it's likely you want frame exact filtering,
> > and not hope that the timestamp will match that exact frame.
> You do not have to hope that the timestamp will match the exact frame, you
> just have to give the correct timestamp.
> > A typical editing FFmpeg application would provide a GUI with a user
> > editable timeline frame based for the user, and the app would construct a
> > sendcmd filtergraph to feed a ffmpeg.
> The GUI adds a "pts" field to the data structure it uses to store the frames
> and uses it to build the sendcmd script.
OK, assuming we are sure to have different PTS set for every single frame
(so monotically increasing, no NOPTS, ...). A counter is way easier to
deal with, and is sure to not differ between different apps (contrary to
timestamps where you could have rounding and stuff).
> > Does that sound like a very specific case to you? IMO, even editing in
> > command line, assuming you could get the frame id (through SMPTE timecode,
> > or with a drawtext printing frame number in ffplay + the next frame
> > feature like '.' in MPlayer), it could be pretty useful.
> I do not know exactly what SMPTE timecode is supposed to do, but as for the
> other example, you can as easily get drawtext to print the timestamp than
> the frame number. Actually, MPlayer already does it: -osd-fractions 1.
The SMPTE timecode is just a frame counter, expressed as a timestamp +
frame-id-in-the-current-second. It gives a hint about the time, but you
are also sure to not have any duplicate. It applies to only a few
restrictive frame rate thought. That's what is being used in editing to
> > I'd say that frame accurate editing is quite common and justified (maybe
> > nine times out of ten).
> Yes, frame-*accurate* is necessary. But timestamps are microsecond-accurate:
> even taking a large margin to guard against rounding errors, they still are
> accurate enough to grant frame-accuracy.
Maybe. I think users are not confident with it, maybe for specific issues
such as -ss not being very exact for example. "Why will the sendcmd filter
have exact timing but -ss won't?".
While it may not be justified to use it all the time, what's the problem
about allowing another unit, which is more spatial than temporal?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 490 bytes
Desc: not available
More information about the ffmpeg-devel