JVLC status

[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

[adanecito]

Okay I read your comments about 1.1.0 to 1.1.1 but no mention of the issue regarding setVideoSurface() and recasting to use it. Not that I expected details but that is why I looked at the test case examples and frowned and left this message.

I did the link to the log4j but haveing the users download around 500KB for logging seems excessive not your fault just the cost of that logging package.

I need to focus back on the issue of creating a vlc instance taking forever next.

Thanks,
-Tony

[sherington]

Okay I read your comments about 1.1.0 to 1.1.1 but no mention of the issue regarding setVideoSurface() and recasting to use it. Not that I expected details but that is why I looked at the test case examples and frowned and left this message.

Well, I do say to use the specific type of media player the factory returns rather than the base-class. I accept I could have been clearer though.

I need to focus back on the issue of creating a vlc instance taking forever next.

Is this in your own application or with my test player? Because my test player was definitely broken in that release (hard-coded plugin path), but I've fixed it now.

If it's your own application I'm puzzled.

I'm happy to help you directly if you email me.

[sherington]

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

Sorry I missed this message the first time.

For log4j, go to logging.apache.org. I needed to add some logging while developing the bindings because it helps pinpoint crashes. Once the bindings have stabilised for some time I will remove log4j completely and maybe put my own lightweight logging in there. If you choose to remove the log4j stuff yourself, that's absolutely fine.

Regarding setVideoSurface - you do not have to do anything for a particular OS since EmbeddedMediaPlayer has the method you're looking for - that's the type the factory returns and is not OS-specific.

[adanecito]

Hi Sherington,

Thanks I looked to deep into the setVideoSurface and saw the class for windows instead of looking at what was returned.

I did change my app code to use the latest vlcj and log4j so now I am in sync. At least now I am back to the mediaPlayer instance being created but the video not running since I am not getting any events generated from the adaptor.

I have updated my simple example in eclipse and it runs and I pointed the plugins dir to where it was installed by the app and the same options as what the app uses.
I will see how to setup debug mode since I think you set it up to return all messages that are sent to the message window in vlc? That would be usefull if I can get those messages.

Thanks,
-Tony

[sherington]

I will see how to setup debug mode since I think you set it up to return all messages that are sent to the message window in vlc? That would be usefull if I can get those messages.

For the log output did you try the usual "-vvv" libvlc args?

Or, the new vlcj exposes the native log if you want to use that, look at MediaPlayerFactory.newLog(), Log, and LogHandler.

[adanecito]

Hi Sherington,

I have tried -vvv in the past and it never worked for me and the same issue with native log. I seem to remember the vlc team saying logging was broken.

I will look at MediaPlayerFactory.newLog().

I did fix the remaining issue (around 5:00AM my time) where I was playing youtube videos with my app. So now I can play them again using 1.1.2 nightly.

Regards,
-Tony

[sherington]

I did fix the remaining issue (around 5:00AM my time) where I was playing youtube videos with my app. So now I can play them again using 1.1.2 nightly.

Do you have any remaining issues with the latest vlcj?

[adanecito]

Hi Sherington,

None that I know of unless you can get the fullscreen to work like it used to in 1.0.6

Otherwise everything is fine. I might start a different thread regarding video stalling where the same video but in a smaller window is slower than one in a large window. I do not see CPU issues but that is my next area to verify and try to isolate fro the VLC team unless they have observed that behavior. I was too busy with cookies and web start last night to worry about some oddity that may not exist.

Thanks so much for the support!
Tony Anecito
Founder,
MyUniPortal
http://www.myuniportal.com

[Maco_]

I have a problem with the videoSurface and JSplitPane in my program. I can enlarge the videoSurface but can't shirk it.

To reproduce this problem you can replace the line 219 in TestPlayer.java to this:

Code: Select all

JSplitPane splitPane = new JSplitPane(); splitPane.setLeftComponent(videoSurface); splitPane.setRightComponent(new JButton("Other thing")); mainFrame.add(splitPane, BorderLayout.CENTER);

The result is:

Code: Select all

mainFrame.setLayout(new BorderLayout()); mainFrame.setBackground(Color.black); JSplitPane splitPane = new JSplitPane(); splitPane.setLeftComponent(videoSurface); splitPane.setRightComponent(new JButton("Other thing")); mainFrame.add(splitPane, BorderLayout.CENTER); mainFrame.add(controlsPanel, BorderLayout.SOUTH); mainFrame.add(videoAdjustPanel, BorderLayout.EAST);

This happens in vlcj 1.1.4. In the 1.1.3 happens the same.

Someone know why this happend?

Thanks.

[sherington]

I have a problem with the videoSurface and JSplitPane in my program. I can enlarge the videoSurface but can't shirk it.

A couple of things working in isolation or together may be causing this...

1. The test player you're referring to sets an explicit size on the video surface component (videoSurface.setSize(w,h))
2. The canvas component has a 'natural' minimum size that you are hitting

The JSplitPane won't shrink a component smaller than it's minimum size.

So what to do about it, try one or more of...

a) Explicitly set a minimum size on the canvas to something smaller
b) Don't set an explicit size on the video surface component (the test player does this just because, well, it's only a test player - there's no reason your own app has to do it).

You can also try one or more of setSize, setMinimumSize, setMaximumSize, setPreferredSize!

I just verified this in the test player and the video does indeed grow/shrink as you drag the split pane (at least until the canvas gets to it's minimum width/height.

In short, it looks like if you do canvas.setSize(w,h) the split pane will not shrink the canvas below w,h.