[FFmpeg-devel] [RFC] Move ffplay engine to separate library

[Stefano Sabatini]

On date Sunday 2013-11-24 02:35:45 +0100, Lukasz M encoded:
> >
> > > One important thing I skipped is a support for filters. I just used src +
> > > sink for implicit format conversion when needed.
> > > Can you elaborate what you mean by an efficient way to build the
> > > filtergrapth?
> > > I honestly didn't investigate filter module deeply yet, but as far I see
> > it
> > > is usually built by providing a string with description of filtergraph.
> >
> > See for example doc/examples/filtering_video.c.
> >
> > Right now the user has to create a source, create a sink, setup
> > inputs/outputs and parse the provided graph, then finally configure
> > the resulting filtergraph. This could be probably embedded by some
> > high-level utilities.
> >
> 

> OK, but you said more efficient. The description suggest it to be "just"
> simpler.

More "efficient" in terms of programming.

> I'm not saying it is not important, but it is just about that?

> If so then why not just copy paste from ffplay into libavfilter?

As a first approach, then fine-tune it in order to have a sane API.
 
> For a player this could be a bit simpler, since you could use a movie
> > to work as source (and letting it do the decoding), the feasibility of
> > this approach has to be verified yet (since I never did it, and other
> > users usually provides no feedback so we basically don't know).
> >
> 
> I think I missed some important thing in ffmpeg. What you mean by movie?

The movie source, documented in the multimedia sources section.

> Also users may need to build a filtergraph not relying on the parsing
> > facilities, but building the graph by hand (at least we had some
> > requests of this kind IIRC).
> 
> 
> I was thinking about something like that. To provide API like:
> insert_filter_before(...)
> insert_filter_after(...)
> disable_filter(...)
> enable_filter(...)
> remove_filter(...)
> ...
> Probably filtergrapth have to be reconfigured anyway after that and it will
> not be much more efficient,

Reconfiguration is something we still lack. Note that we have the
so-called "timeline support" which allows to enable/disable through
commands the enabled filters.

> but some extra string parsing can be avoided and it see it more natural to
> maintain objects than a string (sorry for c++ language),
> and again: I'm not familiar with filters yet :]
> 
> 
> > > This is just high level vision, but I see that player should be possible
> > to
> > > change filter's parameters at runtime. (I'm not sure, but I have feeling
> > it
> > > was discussed somehow)
> > > For example, you may put volume filter connected somehow with a slider in
> > > player's UI and changing slider position should just change volume option
> > > in filter config.
> > > I'm aware it is not so simple, but I'm asking for some hints, warning
> > about
> > > pitfalls and your opinion.
> >
> > You can do this using a custom widget filter sending commands to the
> > other filters. Another possibility is to use a command broker
> > receiving commands from external sources (e.g. the zmq filters).
> >
> 

> I tried to catch you on IRC about that. Can you tell what is "custom widget
> filter"? :)

Suppose that you want to create a fancy widget/control filter with an
"Hello kitty" slide bar for tweaking volume, and a strawberry-shaped
rotating knob for changing brightness. In general you want to be able
to deliver a custom widget set to your application, but this filter
clearly should not be part of the library. This could be programmed in
C or created at run-time through scripting. Neither is possible at the
moment.

> There is a rumor you just invented a name for a filter that just not exist
> yet :)

> I haven't test zmq, but I will, but I think sockets are overkill for
> application to communicate with itself, so I need something lighter

Well, zmq is meant for an *external process* sending commands/events
to the libavfilter process. You can simply inject a command through
the command API.

> NOTE: --enable-libzmq cause build break on ubuntu 12.04 LTS - it has old
> version 2.1
> Some backports may still be useful.

I based my coding on version 3, and I realized the backport changes
were not trivial since the API changed in significant ways, and I had
not any motivation for doing it.

> 
> One (minor) problem is that you need to use a unique identifier to
> > know to which filters you're sending a command (in case many filters
> > instance of the same class are created).
> 
> 
> Does current API allow it to put unique ids to filters? I didn't check it.
> I mean if I put string with filter configuration, may I put some ids too?

Currently not implemented, although the name of every parsed filter is
more or less unique, although in a non very much predictable way (see
zmq examples).

[...] 
-- 
FFmpeg = Frenzy and Friendly Multimedia Portable Enigmatic Gadget