Curious second instance of mplayer

linux_walt · 01-21-2015, 11:07 AM

Hello, when I start a movie in mplayer, 2 mplayer processes are started:

Code:

$ pidof mplayer
20569 20568

One is very active, normal cpu usage you are used to seeing, the other is under 1% cpu usage. When you kill the second one, the active one keeps running for a bit, then freezes. It acts like it ran out of video data from a buffer.

I do have the mplayer cache enabled (2MB). Haven't tried disabling it yet, to see if the second instance of mplayer is still started.

Ok, I disabled mplayer cache. Didn't have to restart the movie, and the second mplayer process vanished.

Interesting.

rtmistler · 01-21-2015, 12:48 PM

Maybe mplayer uses a thread, after all the PIDs are sequential, so the fist one is the one you started when you invoked the command line and the second one is either a thread or a child process which mplayer chooses to use as part of it's architecture. Makes sense considering what you mention as far as usage statistics. What happens if you exit the program normally? Nothing like that? If you kill the first one, does the second one disappear right away? And if you use "ps -ef | grep mplayer" do you find that the second mplayer PID has the first one as it's parent?

linux_walt · 01-21-2015, 01:38 PM

Code:

$ ps -ef | grep mplayer
walter   20547  2003  4 09:45 ?        00:07:02 gnome-mplayer
walter   20682     1 36 11:47 ?        00:11:41 mplayer -vo xvmc,xv, -ao alsa:device=hw=1.0 -channels 2 -af-add export=/tmp/mplayer-af_exporthejgok:512 -quiet -slave -noidle -noconsolecontrols -nostop-xscreensaver -identify -volume 33 -af-add volume=-40.000000:0 -softvol -msglevel all=5 -osdlevel 0 -delay 0.000000 -subdelay 0.000000 -subpos 0 -sub-fuzziness 0 -wid 0xe00018 -brightness 0 -contrast 0 -hue 0 -saturation 0 -alang Zuni,zun -slang Zuni,zun -nomsgcolor -nomsgmodule -nokeepaspect -ass -embeddedfonts -ass-font-scale 1.00 -ass-color ffffff00 -cache 2000 /mnt/hd/video/History/China/China_ A Century of Revolution [1949-1976] Part 2.mp4
walter   20683 20682  0 11:47 ?        00:00:06 mplayer -vo xvmc,xv, -ao alsa:device=hw=1.0 -channels 2 -af-add export=/tmp/mplayer-af_exporthejgok:512 -quiet -slave -noidle -noconsolecontrols -nostop-xscreensaver -identify -volume 33 -af-add volume=-40.000000:0 -softvol -msglevel all=5 -osdlevel 0 -delay 0.000000 -subdelay 0.000000 -subpos 0 -sub-fuzziness 0 -wid 0xe00018 -brightness 0 -contrast 0 -hue 0 -saturation 0 -alang Zuni,zun -slang Zuni,zun -nomsgcolor -nomsgmodule -nokeepaspect -ass -embeddedfonts -ass-font-scale 1.00 -ass-color ffffff00 -cache 2000 /mnt/hd/video/History/China/China_ A Century of Revolution [1949-1976] Part 2.mp4

After killing the most active one, both are terminated. Same if I close the program normally:

Code:

~/src/qt$ pidof mplayer
20683 20682
walter@cubier:~/src/qt$ kill 20682
walter@cubier:~/src/qt$ pidof mplayer
walter@cubier:~/src/qt$

I looked up pid 2003, and that was 'openbox'.

rtmistler · 01-21-2015, 01:44 PM

My take is that this shouldn't be a gripe to you if you were concerned that it was a problem that is. It seems to be just as I was guessing, the top process forks a child or creates a worker thread. Hey if it didn't do that, then the UI widgets to control things would not work efficiently because it'd be spending too much time playing the media. Or vice-versa, the playing of the media would be interrupted whenever you do small things like adjust the sound or something.

linux_walt · 01-21-2015, 02:08 PM

Nope, no gripe. It was going to be a question, then decided to look a little deeper into it, and realized this must be normal behavior. Apparently, enabling buffering requires a second instance of mplayer.

You would think buffering ability would be included into a single instance of the program.