On Saturday, March 8, 2008 at 08:08:55 (-0700) Kevin DeKorte writes:
>-----BEGIN PGP SIGNED MESSAGE-----
>Bill Lear wrote:
>> I have two questions about the mplayer plugin. I am running on
>> x86_64, Fedora 8, firefox 188.8.131.52, 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.
>Also, you might try gecko-mediaplayer + gnome-mplayer and see if they
>give you any better options.
Ok, I was afraid that it was firefox that was doing this. I'll see if
we can get the gecko/gnome combination working to try that out. If
that fails, I guess I'll have to ask the Firefox people if this is
possible. Just for extra information, we had this problem with plain
jpeg images, and I could not figure out how to tell Firefox to display
a window with the image completely filling the window. I fixed this
by using CSS to set the background image of the page as the image in
question and setting it to "no-repeat". Can't do that with movies,
>> 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
>> 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.
I'll have to test this thoroughly to see if I can see any problems
with it, and I'll let you know if I do.
>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.
I would think that shutting down the app correctly includes sending it
a SIGTERM or a SIGINT signal, in which case it should handle it
properly, including stopping the child mplayer and reaping it. A
SIGKILL of course leaves no option to do this, but I would think
the other cases would.
Thanks for your help.