JVLC status

[sherington]

To any vlcj users who may be interested, I made a final 1.1.0 release of vlcj now that vlc 1.1.0 final has been released. Not much has changed if you've been using the recent pre-release 1.1.0x versions.

Please feed back any issues.

http://code.google.com/p/vlcj/

(You also need log4j, jna and the jna platform jars.)

[Jean-Baptiste Kempf]

To any vlcj users who may be interested, I made a final 1.1.0 release of vlcj now that vlc 1.1.0 final has been released. Not much has changed if you've been using the recent pre-release 1.1.0x versions.

Please feed back any issues.

http://code.google.com/p/vlcj/

(You also need log4j, jna and the jna platform jars.)

What about making vlcj the default Java bindings of VLC?

[sherington]

What about making vlcj the default Java bindings of VLC?

To be honest, I can't see myself having the spare capacity to move my project and development environment from googlecode+svn to something new.

[Al3x4nd3r]

vlcj contains a simple video player implementation built using Swing/AWT, and I use this for testing.

I have discovered a new issue that I am really struggling to solve. I did not see this issue with vlc 1.0.5, nor with vlc 1.1.0pre2, but it is present when running the same Java code against vlc 1.0.6 and vlc 1.1.0pre3. I'm not saying this is a vlc fault I'm just describing my circumstances.

The problem goes like this...

1. Start the test player
2. Use file or stream dialog to open a media source
3. Video starts playing
4. Use file or stream dialog, this time hit cancel (or choose something, it doesn't matter)
5. => Fatal JVM failure, with the text below dumped to the error console

(If you never start a video playing, you can open and cancel as many dialogs as you want and it doesn't crash.)

Code: Select all

[????????] x11 video output error: X11 request 20.0 failed with error code 3: BadWindow (invalid Window parameter) X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 20 (X_GetProperty) Resource id in failed request: 0x4400042 Serial number of failed request: 2673 Current serial number in output stream: 2673

The fatal JVM failure is most likely as a result of an unhandled exception condition in the native code.

This happens as soon as the dialog box closes, and is 100% repeatable and I have no idea what to do about it.

I can play movie after movie without any issues if I don't use a dialog box and do it programmatically instead.

Anyone have any ideas?

I had this same problem with JVLC. In fact I do not know how to resolve but I managed to identify that this occurs when you give a second dispose () in dialogs (with video playing).

Code: Select all

package br.ufpb.lavid.GTMDA.Commons.GUI.swing; import java.awt.Component; import java.awt.Dialog.ModalityType; import java.awt.HeadlessException; import java.awt.event.WindowAdapter; import java.awt.event.WindowEvent; import java.io.File; import javax.swing.JDialog; import javax.swing.JFileChooser; import javax.swing.filechooser.FileFilter; /* * To change this template, choose Tools | Templates * and open the template in the editor. */ /** * * @author alexander */ public class JFileChooserGTMDA extends JFileChooser{ private JDialog meuDialog = null; public JFileChooserGTMDA(String path){ super(path); } public void setFileFilter(String description, String... formats){ setFileFilter(new MyFileFilter(description, formats)); } @Override protected JDialog createDialog(Component parent) throws HeadlessException { this.meuDialog = super.createDialog(parent); meuDialog.setDefaultCloseOperation(javax.swing.WindowConstants.HIDE_ON_CLOSE); meuDialog.setModalityType(ModalityType.APPLICATION_MODAL); meuDialog.addWindowListener(new WindowAdapter() { @Override public void windowClosing(WindowEvent e) { cancelSelection(); } }); return this.meuDialog; } public JDialog getDialog(){ return meuDialog; } @Override public int showDialog(Component parent, String approveButtonText) throws HeadlessException { return showDialog(parent, approveButtonText, approveButtonText); } /** * Exibe um jFileChooser. * * @param parent a tela pai * @param approveButtonText o nome a ser exibido do botao de aceitacao * @param title o titulo do jFileChooser * * @return esse eu nao entendi (nao fui eu que fiz esse codigo) */ public int showDialog(Component parent, String approveButtonText, String title) throws HeadlessException { if(approveButtonText != null) { setApproveButtonText(approveButtonText); setDialogType(CUSTOM_DIALOG); } meuDialog = createDialog(parent); meuDialog.setTitle(title); rescanCurrentDirectory(); meuDialog.show(); firePropertyChange("JFileChooserDialogIsClosingProperty", meuDialog, null); return CANCEL_OPTION; } @Override public void approveSelection() { meuDialog.setVisible(false); } @Override public void cancelSelection() { setSelectedFile(null); meuDialog.setVisible(false); } private class MyFileFilter extends FileFilter { String description; String[] formats; public MyFileFilter(String description, String... formats) { this.description = description; this.formats = formats; } @Override public boolean accept(File f) { for(String ext : formats) if(f.getName().endsWith('.'+ext)) return true; return f.isDirectory(); } @Override public String getDescription() { return description; } } }

Try this JFileChooser above that overloads where to dispose() of setVisible (false) and you can "solve" the problem.

[sherington]

I had this same problem with JVLC. In fact I do not know how to resolve but I managed to identify that this occurs when you give a second dispose () in dialogs (with video playing).

Try this JFileChooser above that overloads where to dispose() of setVisible (false) and you can "solve" the problem.

Very nice workaround, thank you.

[Al3x4nd3r]

Hi sherington, nice work with the VLCJ

I have a project that uses JVLC (a manager flows distributed named Arthron soon I will put screenshots here (Project Page in Portuguese Brazil -> http://www.lavid.ufpb.br/gtmda/arthron.html)). And my biggest difficulty with the JVLC can not I change the video effects (and flow effects) without having to restart the Player. I saw that you can add in VLCJ Marquee and Logo in this way. Its possible do this with the video effects ? (Invert, noise ...) Or Change the transcoding line is this way ?


Sorry for my poor english =)

[sherington]

I saw that you can add in VLCJ Marquee and Logo in this way. Its possible do this with the video effects ? (Invert, noise ...) Or Change the transcoding line is this way ?

The marquee and logo is only possible that way because there are new API functions exposed in libvlc 1.1.0. There's nothing that I know about exposed in the libvlc API for those other effects.

[sherington]

I had this same problem with JVLC. In fact I do not know how to resolve but I managed to identify that this occurs when you give a second dispose () in dialogs (with video playing).

Try this JFileChooser above that overloads where to dispose() of setVisible (false) and you can "solve" the problem.

Very nice workaround, thank you.

This is a hard problem to pin down since the workaround is not needed with my 1.1 bindings and vlc 1.1.0 - it all works just fine with 1.1.0, and since that's where everyone should be now I guess we can forget about this particular problem.

[Al3x4nd3r]

Hi Again

VLCJ tested on MAC as follows:

The VLC was in /Applications/VLC.app

So I copied the lib folder (/Applications/VLC.app/Contents/MacOS/lib) and plugin folder (/Applications/VLC.app/Contents/MacOS/plugins) where the project is running. ( I did this because when I put the reference to where VLC was directly installed to the application closing. )

After that I changed the path of the jna.library as follows:

Code: Select all

Properties p = System.getProperties(); p.setProperty("jna.library.path", p.getProperty("jna.library.path") + File.pathSeparator + "lib");

After I changed the -plugin-path= as follows

Code: Select all

String plugin = "--plugin-path=plugins"; this.mediaPlayerFactory = new MediaPlayerFactory(new String[]{plugin});

I also noticed that the MacMediaPlayer was not implemented then did he behave the same as LinuxMediaPlayer (for testing)

Done that could run videos on MAC, but the image is not drawn on the canvas, but in a window outside the application. Also when I was changing the video gave crash (after several attempts) that the error is given below:

Code: Select all

No accelerated IMDCT transform found get_buffer() failed (stride changed) Invalid memory access of location 0x12e75053000 rip=0x7fff87522120 Java Result: 139

I do not know what I gotta do to develop a MacCanvas (similar to what you did with WindowsCanvas). Do you have any tips?

[sherington]

I do not know what I gotta do to develop a MacCanvas (similar to what you did with WindowsCanvas). Do you have any tips?

If I knew what to do I would already have done it.

I have no Mac platform to test on so I simply can't do it blind. I am relying on a Mac vlcj user to tell me what to do. If someone tells me how, I'll implement it.

[Al3x4nd3r]

I am a VLCJ user who has MAC but unfortunately do not know how to help you

[MarkvanDark]

Hi!

First of all, I want to thank you for the greate VLCJ.

But I have a few questions:

1.) Is it possible to have more than one version of VLCJ? For example, if someone has VLC 1.0.6 installed and another VLC 1.1 that the software still works. I thought about selecting one of these two and check which VLC is installed and then load the correct JAR but that would be a bad hack in my opinion.

2.) Before I switched to VLCJ I used JMF within my software. JMF provided me with the time of the video in milliseconds which does VLCJ does not do but which is no problem (dividing by 1000 is no big deal) but I found an issue regarding the time returned by VLCJ: my program needs to be updated every 100ms which is done by a thread. This thread retrieves the current playtime and displays it. JMF returned nearly always 100ms steps but VLCJ sometimes returns twice 0.167 and then the next higher time is 0.384 or something like that. Does somebody know how to tell VLCJ to return always 100ms steps without skipping some times or is it not possible? I cannot go to seconds level because I need to be more granular in case of time.

Best regards,

Markus

[sherington]

1.) Is it possible to have more than one version of VLCJ? For example, if someone has VLC 1.0.6 installed and another VLC 1.1 that the software still works.

Presumably you mean in the same Java application? Not easily. You'd probably have to muck about with Java class loaders and JNA library settings. Just use 1.1!

2.) I found an issue regarding the time returned by VLCJ: my program needs to be updated every 100ms which is done by a thread. This thread retrieves the current playtime and displays it. JMF returned nearly always 100ms steps but VLCJ sometimes returns twice 0.167 and then the next higher time is 0.384 or something like that. Does somebody know how to tell VLCJ to return always 100ms steps without skipping some times or is it not possible? I cannot go to seconds level because I need to be more granular in case of time.

You need to realise the Java bindings are simply calling the underlying libvlc API. When you call getTime() on the Java bindings, you are simply calling the libvlc get_time() function. What you're seeing returned is whatever libvlc is returning at the time you called it.

[MarkvanDark]

Thank you for your answer. Now I have implemented a workaround by using my own timer and retrieving the state of the player which resolves the mentioned issue.

But now I have found another issue regarding the function getVideoSurfaceContents(): it does not return the video surface like in 1.0.3 instead I get a black surface (because I have initialized it black) and if a window is overlaying this part will now be taken as surface but the video itself not.

Is there a bug in this function or is it because VLC has changed its code? How could I else get the currently displayed frame.

And another question: how could I remove the filename displayed within the video when I start to play it?

Thanks in advance,

Markus

[sherington]

But now I have found another issue regarding the function getVideoSurfaceContents(): it does not return the video surface like in 1.0.3 instead I get a black surface (because I have initialized it black) and if a window is overlaying this part will now be taken as surface but the video itself not.

This was never a great implementation because it simply uses the AWT Robot class to do a partial screen capture - that explains why it doesn't work if something else is overlaying it. You could make sure you do window.toFront() before you invoke the method.

If you know of a different way to get what's rendered to a Java component please let me know.

How could I else get the currently displayed frame.

Use the other snapshot function, e.g. mediaPlayer.getShapshot(). This calls the native libvlc snapshot function with a temporary file name, and then it loads that file as a BufferedImage and deletes the temporary file.

And another question: how could I remove the filename displayed within the video when I start to play it?

That's not a Java bindings issue, these are options you pass to libvlc, I can't remember what they are however.

[sherington]

Page 1 of this thread actually has the answer.

Code: Select all

--no-osd --no-video-title-show --no-overlay

[MarkvanDark]

Thank you for your fast answers. I used other paramaters for removing the title.

getSnapshot() is definitively too slow which is why I tried to stick with the Robot solution. I found out why it does not work properly: I had to disable the overlay from VLC which resulted in an invisible overlay for the Robot. That is why the screen capture does not recognize the video and only the background color. I have no problem if a window hovering over the current video is used for the frame.

So here are the two parameters I suggest to use:

vlcArgs.add("--no-video-title");
vlcArgs.add("--no-overlay");

The first one disables the title display on video start and the second disables the overlay for a correct capture. The strange thing was that with version 1.0.3 I did not have to use "--no-overlay" maybe the implementation of VLC works now in an other way.

Best regards,

Markus

[Rémi Denis-Courmont]

edit: okay recompiling the drivers was gonna be more effort than it was worth, i have however installed a 32-bit JDK and run the application in that and it seems to work although i get 'no access module matched "any"' errors. back to the drawing board...

Aren't those type of errors usually because of the plugin-path setting being missing?

yeah. as it turns out i had a relative path to the plugins directory in my code, replaced it with the full path and it all works now.

Setting the plugin path should not be needed. That is to say, LibVLC is supposed to scan for plugins inside the directory from where it was loaded. For instance /usr/lib/libvlc.so will load plugins from /usr/lib/vlc/plugins/. This is supposed to work on Linux and Windows. On BSD and Solaris, the path will be hard-coded at compilation time (which should be OK on those platforms anyway). On MacOS X, there is some autodetection, though I don't know if it depends on the VLCKit.

So unless there is a bug, or you have put the LibVLC run-time in a different place than the plugins, you should not need to care.

[sherington]

I need to be able to adjust the audio delay using my Java bindings and since I could not find any existing function in libvlc to do it, I submitted a patch to the vlc devel mailing list to add functions to get/set the audio delay.

It's a trivial patch that simply calls var_getTime and var_setTime for the "audio-delay" variable. It seems to work just fine for me.

That's the first time I've submitted a patch, and the first time I've used git to make a patch, so apologies if I got something wrong. I hope someone will review and accept it for the next release of libvlc.

Thanks.

[sherington]

Hi,

If you read the "libvlc 1.1.1 news" topic in this forum you will see:

libvlc_video_set_callbacks() and libvlc_video_set_format() allow grabbing video frames from a chosen memory location in real-time

Thanks to a vlcj user contribution we now have this working in the vlcj Java bindings. It's pretty experimental right now and the API will surely change, but if any vlcj users want to try it out (I've had a few people asking me about whether this was possible in Java) then check out the latest code from the vlcj googlecode project and have a look. Any feedback on how this functionality should be presented and used in the vlcj API would be welcome.

You will of course need a very recent build of libvlc from the git repository to be able to use this.

[sherington]

Hello vlcj users,

I made release 1.1.1 of vlcj to go with the newly released vlc. Main changes are to support the new video adjustment methods and the new direct video memory access.

http://code.google.com/p/vlcj

All feedback appreciated.

[adanecito]

Hi Sherington,

I tried also sending an email directly to you via hotmail but no reply yet so leaving message here.

I downloaded your 1.1.1 version released 7/23 since I was upgrading to the latest vlc nightly builds.
I get an exception about mediaPlayer.setVideoSurface() not existing. It used to work a couple of months ago.

Seems like you implemented (sort of because you leave nativeSetVideoSurface() to us to implement) EmbeddedMediaPlayer which is returned from the MediaPlayerFactory but your Test examples use MediaPlayer so the setVideoSurface() fails.

If I use EmbeddedMediaPlayer instead of MediaPlayer your adaptor code fails
because it expects MediaPlayer.

Are you still in the middle of changes for 1.1.1 you released 7/23?

How do I work around this situation?

Thanks,
-Tony

[adanecito]

Ok I recasted the mediaPlayer object to WindowsEmbeddedMediaPlayer for the setVideoSurface() and can compile. Bad news is when creating the instance of vlc the code now hangs as if the creation is taking forever. This is new since I upgraded to vlcj 1.1.1. I will let you know what I find. Please update your test code because you might run into the same issues I am.

Thanks,
-Tony

[sherington]

Ok I recasted the mediaPlayer object to WindowsEmbeddedMediaPlayer for the setVideoSurface() and can compile. Bad news is when creating the instance of vlc the code now hangs as if the creation is taking forever. This is new since I upgraded to vlcj 1.1.1. I will let you know what I find. Please update your test code because you might run into the same issues I am.

Thanks,
-Tony

I always reply to my email, so I must not have received anything from you.

I did reluctantly decide to break the API for 1.1.1 to more easily accommodate the different types of media player, that's why you had to change your client code. This is mentioned on the web-site.

D'oh. I just spotted what's wrong. For the release 1.1.1 test jar I hard-coded a plugin path to load libvlc (I swap between the official release and my own build regularly!) that will only work on my machine. I'll withdraw that jar and post a one that works.

Sorry about that and thanks for reporting it.

[adanecito]

Hi Sherington,

It was only one issue so far with a small change it's I am just not sure you intended that to happen with the setVideoSurface since that means the users of the vlcj api now have to add a reference to a particular OS which I think you were trying to avoid? I will add code changes to accomidate different OS's now for just that one method. I will check the web site for anything else I might have missed.

What is the purpose of using a LOG instance of libvlc? Is that the default now for the instance? I have not included log4j with my deployment so commented out all the log statements and used the old non-logging instance of libvlc. Will that be an issue with 1.1.1 vlcj? I will look into adding log4j any vendor and specific version I need to deploy? There seem to be multiple sources for log4j.

Thanks,
-Tony