[FFmpeg-devel] ffplay.c - improve design (without adding features)until looks good

Don Moir donmoir at comcast.net
Wed Jul 25 01:37:58 CEST 2012

----- Original Message ----- 
From: "Stefano Sabatini" <stefasab at gmail.com>
To: "FFmpeg development discussions and patches" <ffmpeg-devel at ffmpeg.org>
Sent: Tuesday, July 24, 2012 6:09 PM
Subject: [FFmpeg-devel] ffplay.c - improve design (without adding 
features)until looks good

> On date Tuesday 2012-07-24 12:43:20 -0800, Lou Logan encoded:
>> On Tue, 24 Jul 2012 04:50:26 +0200, Juan Manuel Borges Caño wrote:
>> > First, I decided to use your library in some projects because simply 
>> > you
>> > don't have a nearl competitor with this quality.
>> > http://code.google.com/p/openmedialibrary and
>> > http://code.google.com/p/openalextensions .
>> >
>> > With that knowledge i have a concern, documentation was lacking 
>> > everywhere,
>> > and even not that is enough, ffplay.c could have saved all it, but the 
>> > code
>> > is so messily cluttered with features hacked together without desgin
>> > concerns in mind, that the look was unusable out of a copy/paste and 
>> > use,
>> > which could not be because i'm not using the sdl library. If the desgin 
>> > of
>> > ffplay.c were made clear it would be a better reference documentation 
>> > and
>> > become more plausible to reuse some code and/or learn from it.
>> >
>> > Perhaps you don't get that feeling, but from what i've seen, it is so
>> > cluttered that makes 10x difficult to follow. Though i know your 
>> > library is
>> > very powerful and haves a lot of features.
>> >
>> > To summarize, like talking programming design course, improve the 
>> > coding
>> > design of the program and/or even start giving him some love and do an
>> > ffplay folder so the code starts to split and grow, and even you 
>> > support
>> > more backends like opengl/openal yourself, or framebuffer even. If that
>> > become unusable you would need to almost do that in the docs, so... 2 
>> > for 1
>> >
>> > Nice work, don't stop it.
>> Patch(es) Welcome™
>> We are all volunteers and time is limited which unfortunately can make
>> documentation lacking. I assume you are now somewhat familiar with the
>> code, so perhaps you could contribute. Contributions are appreciated
>> and if you need any help feel free to ask in #ffmpeg-devel.
> [I edited the subject since I find a bit aggressive to address a
> developer in it, especially considering that Marton took over ffplay
> maintainership just recently and he already did a good amount of work
> for addressing some of its shortcomings.]
> And yes there is a lot which can be improved, one of the problems is
> *history*, for example ffplay.c supports two codepaths for rescaling
> (integrated resampling and using libavfilter). Subtitle overlaying
> should be addressed at the filtering level, and we could drop "native
> audio visualization" once we have the corresponding display filters in
> libavfilter (e.g. rdft visualization).
> Another planned task was to support more backends (an opengl output
> backend would be definitively welcome), but to do it the proper way
> (c) would require to review the libavdevice design.
> Also since someone mentioned money, Marton or another developer could
> create a kickstarter project related to ffplay reshaping, and start to
> work on it if the community shows some interest and is able to reach
> the funding goal.
> -- 

One Point: I am happy not using SDL, or some other OpenThing to do my video 
and audio output and FFmpeg allows me to do that.

Agree that ffplay.c should be a better model for using FFmpeg. There tends 
to be a steep learning curve in the long run.

Mostly, when you run into problems, the developers do a good job of getting 
them fixed. But questions arise and can be difficult to find an answer. Also 
some problems go into limbo and just sit.

Right now you can post a bug report and hope it will be addressed. It would 
be good if there was one person you could goto and it was his responsibility 
to see that it got fixed, document the problem, set a timeline on it, and 
notifying the right developer to get it fixed. Or someone to find an answer 
for you without spending hours yourself trying to find answer.

This could be a pay for use service. Get people to pay somehow so things can 
be improved.

FFmpeg does some amazing things, but you need to do something to get it to 
the point of a more professional and commercial qualty level and with much 
improved documentation.

As it stands, FFmpeg works very well for me (not without pain :), but still 
a handful of problems which are generally bugs in FFmpeg that I can't work 
around and looks like they will never be addressed. 

More information about the ffmpeg-devel mailing list