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

[Stefano Sabatini]

On date Saturday 2013-11-23 01:26:05 +0100, Lukasz M encoded:
> On 1 October 2013 12:53, Stefano Sabatini <stefasab at gmail.com> wrote:
[...]
> > For example you could have something like this:
> >
> > [input device] -> [movie source] -> [filters] -> [output device]
> > |--------------------------------------------------------------|
> >                             ^
> >                             |
> >                             v
> >                     [control device]
> >
> > and provide some way to send interactive commands, e.g. to adjust
> > filtering and/or to seek back.
> >
> > What we lack right now, amongst the other things: better output
> > devices (e.g. opengl, audio outputs), an efficient way to build the
> > filtergraph, more filter commands (e.g. to seek back in the movie
> > source), and a high-level API and/or high-level language bindings.
> 
> 
> A bit old topic, but I was working on it in spare time.
> Your vision of it work well. I made proof of concept and a simple player
> using pulseaudio + xv work well.
> It has very similar cpu and memory usage as ffplay.

Nice. 

> 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.

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).

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).

> 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).

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). The other most serious issue
is that you don't want to create a control filter by hand in C,
ideally you want to make use of a scripting language. Of course I
suppose the control module should not necessarily be a filter,
provided it has access to the filtergraph.

The problem with a scripting filter is that:
1. you need to make it public the interface used by filters (right now
it is mostly private), and make it possible to create filters outside
the library, and register them at run-time.

2. you need to provide a few FFmpeg utilities to the scripting
filters, that is you need to create a binding for the
control filter/component language.

Problem 1. is relevant also for C-language filters, in case you decide
to code the control module in C.
 
> Other thing that concern me is want you mean by filter command to seek back
> in the movie? I assumed seeking require change a position in a stream at IO
> level (protocol).

This should be easy enough, we just need to add a seek command to the
movie source.
-- 
FFmpeg = Funny & Frightening Magnificient Portable Erotic Gadget