Javier Gálvez Guerrero | 1 Oct 12:06 2008
Picon

Re: Slave mode bugs (?) and Java Swing embedding

Hi Mathieu,

2008/9/30 Mathieu SCHROETER <mathieu.schroeter <at> gamesover.ch>:
> Javier Gálvez Guerrero a écrit :
>> In order to analyze if MPlayer is such a possible candidate I've
>> downloaded it (1.0rc2-4.2.3 in Ubuntu Linux, through Synaptics) and
>> given it a try.
>
> <snip>
>
>  > MPlayer plays nicely all added items but if I try to "restart" the
>  > playlist (loadfile path/to/new/file0 0) MPlayer stops playing the
>  > current item,
>
> The last parameter of loadfile is used to *append* when != 0.

Yes, I know that. That's why I use it to add different contents in
sequence (thus, creating a playlist). Adding 0 or nothing has (or
should have...) the same effect: start playing the file given as the
first argument. What I get is not this, but restarting the current
item. Note that this ONLY happens when, after adding many files to the
list with 'loadfile path/to/file X' and playing an item different from
the first one, I try to play a new item (thus restarting the playlist)
with 'loadfile path/to/new/file' or 'loadfile path/to/new/file 0'.

This is the MPlayer output:

loadfile path/to/first/file   <--------- start the playlist with this first item
...
starts playing first item
(Continue reading)

Alex Sherwin | 1 Oct 14:03 2008
Picon

Re: Slave mode bugs (?) and Java Swing embedding

I do this in a  Java now.  You can use Swing or SWT (SWT is actually
easier, they expose the window handle  on frames, in Swing you have to
use a hack that is not "supported" in the JDK, but exists and works
from 1.4.2 to the latest 1.6)

Unfortunately, if you read the man page for the -wid option, you will
see that it only works on Windows.  I've spent awhile trying to find a
way to make a x-platform java Swing or SWT app that will embed MPlayer
on Windows Linux and OS X through Java Web Start.  The closest I've
been able to come is to deliver an app that embeds MPlayer on Windows,
and provides a slimmed down interface on Linux and OS X to control
mplayer, which will open its own video display window.

I spent a bit of time on this mailing list and the IRC channel trying
to figure out a way, and had someone point me to the code where the
MPlayer GUI manages to embed the player, but this is able to do it
using shared memory segments to paint the display (which you would not
be able to accomplish with Java)

Good luck on Linux, but I'm going to say its not possible...

On Wed, Oct 1, 2008 at 6:06 AM, Javier Gálvez Guerrero
<javier.galvez.guerrero <at> gmail.com> wrote:
> Hi Mathieu,
>
> 2008/9/30 Mathieu SCHROETER <mathieu.schroeter <at> gamesover.ch>:
>> Javier Gálvez Guerrero a écrit :
>>> In order to analyze if MPlayer is such a possible candidate I've
>>> downloaded it (1.0rc2-4.2.3 in Ubuntu Linux, through Synaptics) and
>>> given it a try.
(Continue reading)

Kevin DeKorte | 1 Oct 15:00 2008
Picon

Re: Slave mode bugs (?) and Java Swing embedding


Alex Sherwin wrote:
> I do this in a  Java now.  You can use Swing or SWT (SWT is actually
> easier, they expose the window handle  on frames, in Swing you have to
> use a hack that is not "supported" in the JDK, but exists and works
> from 1.4.2 to the latest 1.6)
> 
> Unfortunately, if you read the man page for the -wid option, you will
> see that it only works on Windows.  I've spent awhile trying to find a
> way to make a x-platform java Swing or SWT app that will embed MPlayer
> on Windows Linux and OS X through Java Web Start.  The closest I've
> been able to come is to deliver an app that embeds MPlayer on Windows,
> and provides a slimmed down interface on Linux and OS X to control
> mplayer, which will open its own video display window.
> 
> I spent a bit of time on this mailing list and the IRC channel trying
> to figure out a way, and had someone point me to the code where the
> MPlayer GUI manages to embed the player, but this is able to do it
> using shared memory segments to paint the display (which you would not
> be able to accomplish with Java)
> 
> Good luck on Linux, but I'm going to say its not possible...

Incorrect, the -wid option works perfectly fine on X (Linux/BSD).

Kevin

--
Get my public GnuPG key from
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7D0BD5D1
(Continue reading)

Bart van Deenen | 1 Oct 16:38 2008
Picon

Re: Slave mode bugs (?) and Java Swing embedding

On Wednesday 01 October 2008 15:00:33 Kevin DeKorte wrote:
> Alex Sherwin wrote:
> > I do this in a  Java now.  You can use Swing or SWT (SWT is actually
> > easier, they expose the window handle  on frames, in Swing you have to
> > use a hack that is not "supported" in the JDK, but exists and works
> > from 1.4.2 to the latest 1.6)
> >
> > Unfortunately, if you read the man page for the -wid option, you will
> > see that it only works on Windows.  I've spent awhile trying to find a
> > way to make a x-platform java Swing or SWT app that will embed MPlayer
> > on Windows Linux and OS X through Java Web Start.  The closest I've
> > been able to come is to deliver an app that embeds MPlayer on Windows,
> > and provides a slimmed down interface on Linux and OS X to control
> > mplayer, which will open its own video display window.
> >
> > I spent a bit of time on this mailing list and the IRC channel trying
> > to figure out a way, and had someone point me to the code where the
> > MPlayer GUI manages to embed the player, but this is able to do it
> > using shared memory segments to paint the display (which you would not
> > be able to accomplish with Java)
> >
> > Good luck on Linux, but I'm going to say its not possible...
>
> Incorrect, the -wid option works perfectly fine on X (Linux/BSD).
>
> Kevin

Here's some x-platform code that I use to get the wid of an awt canvas. Works 
fine on Linux and Windows.
The ExtendedCanvas.java is used to generate the ExtendedCanvas.h header file
(Continue reading)

Reimar Döffinger | 1 Oct 19:12 2008
Picon
Picon

Re: Slave mode bugs (?) and Java Swing embedding

On Wed, Oct 01, 2008 at 12:06:25PM +0200, Javier Gálvez Guerrero wrote:
> Adding 0 or nothing has (or
> should have...) the same effect: start playing the file given as the
> first argument. What I get is not this, but restarting the current
> item.

Well, what it should do is: delete the current play list, add the given
file and then start playing the first file in the play list.
That first step was messed up, because loadfile with != 0 parameter
added the files at a wrong (invalid) location.
I think it should work as expected in latest SVN, though I did not test
it that much.

Greetings,
Reimar Döffinger

Gmane