[FFmpeg-devel] ffplay.c Marton Balint - improve desing (without adding features) until looks good
cus at passwd.hu
Thu Jul 26 00:44:29 CEST 2012
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 .
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
> 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
- 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
> 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
More information about the ffmpeg-devel