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

[Stefano Sabatini]

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.
-- 
FFmpeg = Fostering & Fundamental Martial Puritan EntanGlement