m4myo / python-mplayer

Automatically exported from code.google.com/p/python-mplayer
GNU Lesser General Public License v3.0
0 stars 0 forks source link

Independent mplayer process #8

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Hi,

I am not sure this is the right place for the question, but I wouldn't want to 
pollute the wiki pages.
Anyway, I have done related work interfacing mplayer through a remuco 
(code.google.com/p/remuco) adapter.
Our problem has always been getting information from the player, as it seems to 
export it solely to stdout.

I took a very quick look and so far you are always running mplayer in slave 
mode. Is that true? Have you tried to talk to a player which is already running?
Maybe we can help each other.

Congratulations on your work :)

Original issue reported on code.google.com by igor.con...@gmail.com on 3 Aug 2011 at 12:44

GoogleCodeExporter commented 9 years ago
Hello,

Yes, python-mplayer runs MPlayer in slave mode. For all the python-mplayer 
classes, all of MPlayer's stdout output is read continuously and is placed in a 
queue.Queue() object (for thread-safety). Once the wrapper sees a get_property 
command to MPlayer, it tries to fetch an item from the queue. In other words, 
communication is still done asynchronously since there's no other way of doing 
it.

To add more detail, the different classes use different ways of reading the 
stdout output from MPlayer. In the base Player class, separate threads are 
used. In AsyncPlayer, the asyncore framework takes care of it. In 
GPlayer/GtkPlayerView, the GObject/GTK main loop processes the I/O events. In 
the case of QtPlayer/QPlayerView, the Qt main loop does this.

I hope this helps.

P.S.:
You can just email me directly. :)
I will close this issue now.

Original comment by daru...@gmail.com on 14 Aug 2011 at 12:32