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

Conrad Wood mplayer at conradwood.net
Thu Oct 10 10:51:07 CEST 2013


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.

Basically, the UI is a remote-controlled media-station running on an
embedded system with HDMI-out to a TV and Digitial-Audio to an amp. 
The embedded system is remote-controlled by android/iPhone app and a
webinterface.
Without removing the buffer it takes annoyingly long (from a user
experience) before the UI corresponds to the stream.

tbh, I don't see any noticable performance impact on mplayer, since it
currently submits entire lines to libc which in turn buffers it. Mplayer
would still submit entire lines to libc, which simply does not buffer
it. 






More information about the MPlayer-dev-eng mailing list