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

[Conrad Wood]

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.

Hi,

Sorry for late reply - I have been quite busy lately.

yes, using -identify makes more sense ;)
However they also appear to be buffered from what I observe on the pipe
connected to it.

Also - if mplayer does start again, there has to be some output to
signal to the gui that it did start playback.
Currently I parse "Playback started" - which also is as of yet buffered
and causes delay in the responsiveness of the gui unless I apply my
patch.