[MPlayer-dev-eng] patch: Make stdout unbuffered in slave mode

[Reimar Döffinger]

On Thu, Oct 10, 2013 at 10:51:07AM +0200, Conrad Wood wrote:
> On Thu, 2013-10-10 at 09:18 +0200, Reimar Döffinger wrote:
> > On 08.10.2013, at 15:30, Conrad Wood <mplayer at conradwood.net> wrote:
> > > attached Patch sets the standard output to non-buffered, if mplayer is
> > > in 'slave' mode.
> > > 
> > > This has the benefit that a reader connected to mplayer via pipe is a
> > > lot more responsive (feels faster for the user) since the mplayer output
> > > is passed into the pipe (and thus the UI) immediately.
> > > 
> > > I assumed that this is the case almost always when mplayer is invoked
> > > with '-slave' mode.
> > 
> > What does your UI need stdout for?
> > I believe (sorry, being lazy and did not check in the code yet) the slave mode messages are supposed to come through stderr which is unbuffered anyway.
> > I don't like the performance aspects of disabling buffering, I'd rather add explicit flushes at chosen critical points if necessary.
> 
> 
> The UI needs to parse, for example, "Video: no video" or "Selected video
> codec:", "Clip info:", "Playback started" and a few more things mplayer
> tells it. And, of course standard slave-mode answers like
> "ANS_TIME_POSTIION", which currently go to stdout but appear to be
> flushed already.

Actually they _all_ should already be flushed, see the fflush in mp_msg.c,
line 245.
Can you figure out why it is not enough?
Also you should avoid using anything that is not part of -identify,
those messages like "Clip info:" might be translated, in which case
your UI will break.
The "ID_CLIP_INFO_*" stuff in contrast is safe from such issues.
There is also ID_VIDEO* for the first two.
It seems we might be missing some -identify equivalent for
"Starting playback..." but I wonder if there's really any need/point
for that?
It will come right after the codecs have been printed.