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

[Reimar Döffinger]

On Mon, Nov 04, 2013 at 07:58:56PM +0100, Conrad Wood wrote:
> On Tue, 2013-10-15 at 21:17 +0200, Reimar Döffinger wrote:
> > 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.
> 
> yes, using -identify makes more sense ;)
> However they also appear to be buffered from what I observe on the pipe
> connected to it.

As said, they are all flushed, why does the flush not work?
Also, does _IOLBF work any worse than _IONBF?