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

[Lukasz M]

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

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?

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,
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"? :)
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
NOTE: --enable-libzmq cause build break on ubuntu 12.04 LTS - it has old
version 2.1
Some backports may still be useful.

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?


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


I wanted to make high-level C API first. So thousands lines of code are
covered by few functions.
And control module something like this:
[FFmpeg api] <-- [hight level API [control module inteface]] <-- [controle
module]
So there is an API (additional library) that simplifies ffmpeg usage and
this library has bidings to scripting languages and [maybe] another layer
of control protocols like telnet, jsonrpc, REST etc...
I have never made biding to script language, so I don't know if I say
something stupid, but script API should also be high level and easy.