Re: Displaying videos with no internal border, child mplayer problems

On Saturday, March 8, 2008 at 08:08:55 (-0700) Kevin DeKorte writes:
>-----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.
>...
>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,
though...

>> 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.

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.


Bill

-------------------------------------------------------------------------
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/