Re: Displaying videos with no internal border, child mplayer problems
Kevin DeKorte <[email protected]> Sat, 08 Mar 2008 08:08:55 -0700
| Newsgroups | gmane.comp.mozilla.mplayerplug-in |
|---|---|
| Message-ID | <[email protected]> |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bill Lear wrote: > I have two questions about the mplayer plugin. I am running on > x86_64, Fedora 8, firefox 2.0.0.12, mplayer 1.0rc2-4.1.2 > > First, I am trying to display the video in a firefox window and would > like to display only the video (no controls, progress bar, etc.) and > need the video to fill the entire window, all the way out to the edge, > with no internal border. However, after plowing through the source > code (plugin.cpp, plugin-setup.cpp, plugin-ui.cpp), I can't see where > this internal border is set and how to disable it. Could someone > here please help me figure this out? > I believe the boarder you are referring to is set in Firefox. There is no border used in mplayerplug-in. Firefox gives a window and the fill size of it is used. Now mplayer may use a black boarder around the image if it scaling it. You might look at the command that mplayer is started with by looking at plugin-thread.cpp and look at the SetupPlayer function. Also, you might try gecko-mediaplayer + gnome-mplayer and see if they give you any better options. > Second, I have noticed two things about how child mplayer processes > are handled. First, when mplayer exits after it has finished playing > a video, child processes are not reaped, and after playing many videos > this can cause a problem, as the process I have in mind would be very > long-lived. I checked the source code, and a line in > plugin-threads.cpp: > > signal(SIGCHLD, sig_child); > > was commented out. When I uncomment this (recompile, reinstall), > the children are reaped properly. Is there any reason not to install > the sig_child signal handler? > > The second thing about how child mplayer processes are handled is more > troubling. When firefox is killed (say, by pressing control-C at the > command-line or issuing 'kill' from the command line), I often see an > mplayer process left over, but in this case it is not just an idle > unreaped child, but an mplayer that is galloping along, chewing up all > of the CPU that it can get. On occasion I will see more than one of > these, though it may be due to multiple start/stops of Firefox. I > would assume that when SIGKILL comes through, the mplayerplugin should > then kill the child mplayer process, do any other clean up necessary, > and exit. Is there a reason this is not done (if indeed it is not) > or why this may not be working properly? The sigchild event was disabled due to some concerns that the wrong mplayer was being killed off when a window was closed. I never saw this myself, but I changed this due to some bug reports. As for mplayer not dying if firefox crashes or is killed.. Well really there is no way to shutdown mplayer if the hosting application suddenly goes away. Shutdown the app correctly and things are properly reaped. Kevin - -- Get my public GnuPG key from http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7D0BD5D1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfSrAYACgkQ6w2kMH0L1dFpZACfTOrQR04cExhNXO0N12S5FWJE p4gAn3lDMFldWMYnTZ6ZOzPoEvoD2Uw3 =V/Ue -----END PGP SIGNATURE----- ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/