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

[Marton Balint]

On Tue, 24 Jul 2012, 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 .

Great :)
Actually I like it very much. I really think there is a need for an API 
which can be used for playing video, and a lot simpler than the ffmpeg 
API alone.

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

Partially I agree. It is a bit complicated, and it is full of features. 
FFplay is clearly not a simple media player application for ffmpeg, 
despite the comment in the beginning of the file. There is no doubt it 
can be simplified, if one could rewrite it from scratch.

However, I do think that the basic design of the player is clean:
- A reader thread reads the file and put the audio and video packets to their 
packet queues.
- A video decoder thread decodes the video packets from the video 
packet queue and puts the decoded pictures into the video picture queue.
- An audio thread decodes the audio packets from the audio packet queue 
and returns the decoded audio.
- A refresh thread posts refresh events
- An event thread handles UI events and refresh events

It is a multithreaded design, therefore it is more complex, and thread 
synchronization is a bit hard to follow at first. Also the little features 
make ffplay even more complicated, but these are necessary for a true 
video player: ways to achieve correct A-V sync, changing streams during 
playing, making it work with network streams, frame dropping (as a 
feature), support of video filters...

> 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

Like others already said, that requires a lot of time, and ffplay should 
use the libavdevice framework, which also needs some love before it can be 
used.

>
> Nice work, don't stop it.

Likewise, if you could implement the missing features to your API and keep 
it clean and usable (and fast :)) at the same time that would be a real 
achievement.

Regards,
Marton