VideoLan.Interop a .Net libvlc 0.9.x wrapper

[surf_uk]

I'm glad I referenced your code in the marx' awesome thread, it seams it is THE vlc wrapper - awesomer!

however I'm just getting back into developing my vlc player and only just getting chance to try your mighty wrapper. I have stumbled into a problem already, I don't have the "plugins\libd3dimage_plugin.dll" despite having the latest VLC 0.9.6...

As a result the VideoLanClient class falls over as it cannot find:
InteropMethods.libd3d_surface_changed_callback(cbSurfaceChanged);

I have downloaded your tarball from MeediOS:
http://meedios.svn.sourceforge.net/view ... z?view=tar

I notice this project failed to load during when opening the solution:

Code: Select all

/* The following error has occurred during XML parsing: File: C:\Projects\Auxiliary\VideoLan 0.9.0\D3DImage_Bridge\D3DImage_Bridge.vcproj Line: 10 Column: 2 Error Message: '9.00' violates enumeration constraint of '7.00 7,00 7.10 7,10 8.00 8,00'. The attribute 'Version' with value '9.00' failed to parse. The file 'C:\Projects\Auxiliary\VideoLan 0.9.0\D3DImage_Bridge\D3DImage_Bridge.vcproj' has failed to load. */

So close! can anyone post the dll maybe? - it seams I'm not alone either

[Freundschaft]

ehrm, where do i get the libd3dimage_plugin.dll from?

[publicENEMY]

*deleted*

[surf_uk]

Don't take it personally I'm not the type of guy to flame anything - have changed my quote to:

I'm glad I referenced your code in the marx' awesome thread, it seams it is THE vlc wrapper - awesomer!

Sorry to marx if I did offend, his wrapper has helped me a lot as I posted on his thread. Just found it funny that by posting a link to Kairos vlc interop we now have active engagement with an up to date wrapper, thanks very much Kairos for keeping an eye out and for your contribution!

he DID actually contribute to the community.

In a way I have contributed already by pointing out there's a good alternative I'm trying to get to the point where I can start contributing... wanna help me?

[Kairos]

Sorry about that guys. I broke the build

As was stated earlier in this thread I'm also working on getting VLC into WPF. That is what the D3DImage_Bridge dll is and also the "#if USE_WPF" are doing in the code. I've temporarily removed the project from the 2005 sln file. Currently its more of a proof of concept project. Anyway, it is not needed if you just want to use the wrapper. The wrapper is the VideoLan.Interop.dll. Everything else are just samples or test code.

[Kairos]

@BexX, can you download the new code and try it. I have a feeling the problem was with the way I was finding the plugins directory. I've modified it so it uses Path.Combine which mono should translate into the linux directory structure.

[BexX]

The Problem was caused by these two lines, you have put into an if directive now.

Code: Select all

135 #if USE_WPF 136 cbSurfaceChanged = new D3dCallback(SurfacedChanged); 137 InteropMethods.libd3d_surface_changed_callback(cbSurfaceChanged); 138 #endif

There should not be a problem finding the plugins directory on linux, as these should be located in /usr/lib or /lib, i.e. in the search path, in a proper install. However there is a problem on using the wrapper (similar for jvlc) I encoutered on Ubuntu Interpid: mono will fail to load libvlc.so as it is named "libvlc.so.2" in "/usr/lib/". This can be solved by simply creating an symlink:

Code: Select all

sudo ln -s /usr/lib/libvlc.so.2 /usr/lib/libvlc.so

PS: There is something i forgot to say: Great work kairos! No need to be embaressed! Thumbs up!

[sun_yiqin]

Hi,ALL!
My program throw an exception"The data area passed to a system call is too small"
on running "VideoLanClient videoLanClient = new VideoLanClient();".

Does anybody has the same problem?
Help me! Thanks!

[dlfl]

Plus one on the kudos, Kairos! This looks real nifty!

I ran into a problem with the MediaPlayer.Sample program:
(This is on Windows XP, using the Auxiliary Tarball downloaded tonight and the 0.9.7 VLC binaries.)
First I bulit the solution, absolutely no problem. Then I ran the MediaPlayer.Sample program and got the immediate "could not find dll error" which I expected.
Copied the libvlcore, libvlc dlls and the plugins folder into the bin\debug folder of my solution.
Then the sample program ran fine and I ran it several times.
I returned several minutes later and when I tried to run the program again I got a Visual C++ Runtime Library assertion failed error at line 844 in misc/objects.c.
From that point on the same error always occured when launching the program.

I finally discovered the following:
1. If you append a final backslash to the plugins path constructed in the VideoLanClient constuctor the error doesn't occur.
2. If you use the alternate VideoLanClient constructor and pass the path to the original binary install folder (where I installed the VLC player) the error doesn't occur and it doesn't matter whether you append the final backslash or not (??).

The really strange thing to me is why it worked the first few times before this error started happening? Must be some strange behavior of the Windows OS path handling code ??

Presumably the cross-platform solution to this is to append the Path.DirectorySeparatorChar field.

[innerspace]

I downloaded the 0.9.x interop wrapper today (sourceforge revision 3328) and from first look it seems ideal to fix some problems I have been having in my 0.8.6 application.

However, it wont run!

I have tried both the vlcMediaSample and my own quick player attempt and both get stuck on line 41 (Initialize) of InteropMethods.cs with
{"Unable to load DLL 'libvlc': The specified module could not be found. (Exception from HRESULT: 0x8007007E)"}
Debugging shows its hit at the line Vlc = new VideoLanClient();

I have already removed 0.8.6 (delete pref & cache), installed 0.9.4 and copied EVERY file from VLC root directory plus the plugins to my application debug folder. I remember having this problem before when I tried to test this wrapper.
Even publicENEMY's simple player throws the same error.

Also has anyone done some testing with this wrapper using the nightly 1.0.0 release?
With 0.9.8 (almost-for windows) out I would hope that an upgrade now will be compatible with the first full numbered release of VLC.
There were no visible differences between 0.9.4 and 1.0.0 although I didnt check in detail.

[innerspace]

I got it working by pointing the wrapper to the vlc folder
vlc = new VideoLanClient("C:\\Program Files\\VideoLAN\\VLC");

but this brought me into DennisL's problem of not displaying video on a second opening.
starting a video in VLC reset this.

I solved the problem (I think) by adding the lines below with all dll and plugins in my executables folder

Code: Select all

String appPath = Application.ExecutablePath; String exeName = appPath.Split('\\').Last(); String vlcFolder = appPath.Remove(appPath.Length - exeName.Length); vlc = new VideoLanClient(vlcFolder);

It seems that having empty brackets in the new VideoLanClient() doesnt locate the applications folder as I would expect.

So unless this is fixed in future releases I reccommend anyone using this wrapper to place all dlls and plugins in your apps folder AND tell VideoLanClient WHERE your apps folder is.

I look forward to experimenting more with this wrapper, it seems very good so far.
At last I have position and state change callbacks rather than relying on a very hacked duration check improvisation! Thank you!

[dlfl]

I got it working by pointing the wrapper to the vlc folder
vlc = new VideoLanClient("C:\\Program Files\\VideoLAN\\VLC");

but this brought me into DennisL's problem of not displaying video on a second opening.
starting a video in VLC reset this.
.................

I'm running it this way and don't have the "DennisL problem." This is on two different XP Pro SP3 computers with two different versions of VLC installed, 0.9.7 and 0.9.8.

I resist the idea of having to copy all those files to the runtime folder. Distributing the app to the second computer required just copying the .exe and the interop dll (plus already having VLC player installed).

[innerspace]

Ive now upgraded to 0.9.8 and DennisL's issue seems to be sorted.

Looks like it was a 0.9.4 specific problem. (Im running vista, dont know if thats related at all)

Also now in my simple test player I seem able to initialize vlc without the path to libvlc folder - noticed that the line I was going to add was already there.
However in my main application I get the same error as dlfl

So im still needing to use the fix I mentioned before, although simplified since I remembered an extra command
Any of the 3 appPaths below should work, depending where you position libvlc and plugins

Code: Select all

//string appPath = "C:\\Program Files\\VideoLan\\VLC" //string appPath = AppDomain.CurrentDomain.BaseDirectory; string appPath = Path.GetDirectoryName(Application.ExecutablePath); vlc = new VideoLanClient(appPath);

Thanks Kairos for an excellent wrapper - a few small bugs but they seem easily avoidable, this is definately the best 0.9 wrapper Ive used.

[dlfl]

Is this going to support streaming eventually (or does it already support it and I'm just too dumb to see it)?

I know when you setup streaming in the VLC Player you have to configure a bunch of things such as internet protocol, encapsulation, encoders, etc. I see streams in the object browser for videolan.interop but don't see anywhere to set these items.

[innerspace]

What is the best way for handling VLC exceptions in this wrapper?
Does the statechanged.error get called before an unhandled exception error is sent out?

Not the easiest debugging when I have to wait an hour or 2 for a VLC crash and have a single chance to examine it.

My software runs VLC 24/7 and several times each day VLC crashes and I have to restart playing.

At the moment this requires restarting my entire program but I would much prefer to catch and handle the exception and just start a new instance of VLCMediaPlayer (or would a new VideoLanClient be better?)

[Jean-Baptiste Kempf]

What is the best way for handling VLC exceptions in this wrapper?
Does the statechanged.error get called before an unhandled exception error is sent out?

Not the easiest debugging when I have to wait an hour or 2 for a VLC crash and have a single chance to examine it.

My software runs VLC 24/7 and several times each day VLC crashes and I have to restart playing.

At the moment this requires restarting my entire program but I would much prefer to catch and handle the exception and just start a new instance of VLCMediaPlayer (or would a new VideoLanClient be better?)

Does your RAM increase or your CPU .?

[Valk]

Sorry to ask what feels like a silly question but I could use help getting this right.

Using this excellent wrapper i'm trying to get vlc to connect to a rtsp stream and expose it as a http stream.

Transcoding isn't required (I think, please correct me if i'm wrong).

The stream will be in m2ts or mpeg format (Mediaportal TvServer Stream).

I'm trying to figure out the options I need to set to create the vlc instance, i'd like to run as if a service.
I'd like the final url to be something along the lines of http://<hostname>:<port>/Channel_<number> though i'm open to suggestions.

Also if there is a way to tell if a user is connected to the stream so I can put in a timeout in my code to stop the vlc client that would be a MAJOR bonus since I haven't been able to find anything to achieve that.

Hopefully with this final step i'll be able to stream Live Tv to upnp devices though it would of been nice if tversity supported rtsp to begin with.

Thanks in advance to anyone who can help.

[innerspace]

Does your RAM increase or your CPU .?

It varies from time to time but I rarely see either over about 30-40%

Sometimes the video just freezes and sound continues, sometimes libvlc hits an exception and crashes.
Im hoping to catch those exceptions and restart straight away.

[Kairos]

Currently the wrapper catches most VLC exceptions and then re-throws them as .NET exceptions. You have to catch exceptions in your code using try catch blocks. The StateChanged.Error event is sent out by VLC, I have no idea if an exception is thrown after the event is fired.

Worst case scenario you should dispose you VideoLanClient and create a new one. You may be able to get away with a new VlcMediaPlayer or even just a new VlcMedia depending on what exception occurred. But again I don't know the libvlc internals well enough to give you a definite answer. There should however, be no need to restart the application on a .Net exception. If there is an unhanded internal libvlc exception then thats a different story.

[innerspace]

Where is the best place to position a try catch to handle vlcs .Net exceptions.

At the moment I am only picking them up in my program.cs "static void main" try{} catch{} - but once an error hits this level it logs and restarts the app.

I understand that there is not much I can do for unhandled internal errors (I have other measures in place to deal with these) but would like to handle the thrown ones in a reasonable way.

[justcallmefrank]

Hey mate,

First off I'd just like to say, nice job Was a revelation when I came across this, because the existing bindings I was using were a bit clunky.

I've gone with your approach in regards to the event handling. I'm using one of the UI components to BeginInvoke the events on the UI thread myself which has been working great.

One thing I'm having troubles with which I hoped you might be able to shed some light on, is to do with the Ended event. I'm maintaining my own playlist at the moment, rather than delegating it to VLC. My intention was to capture the Ended event and then pass the next track from my playlist, much the same way I handle next/previous currently. I find though that this locks up if I do this from the UI thread, have you seen anything like this before? I ended up using a BackgroundWorker to start it from another thread. Dodgy, but it works for now. What is your proposed setup for doing this? Should I just be using the MediaListPlayer?

Also, I noticed that when you actually call stop on the player, the state remains on Ended rather than Stopped which is also available. Is this for a reason or just an oversight?

Thanks for the great work though! Very impressed with how it is coming along.

Cheers,
Nathan

[Kairos]

Events block the player thread. If you try to play the next track inside an event then you will cause a deadlock because libvlc is still waiting to return from the event. I too manage my own playlist, the way I do it is by creating a PlayNext delegate then call it inside the event via BeginInvoke method so that it runs asynchronously and doesn't block the libvlc thread. If this code is on a windows form then you could probably cut it down to a one liner using the MethodInvoker, ie..

BeginInvoke( new MethodInvoker( delegate() { PlayNext(); } ) );

If there is a need for it I can always invoke the events on new threads to avoid blocking issues. The way I coded it was to let you handle threading the way you want rather than force you to do it my way. As for the PlayState issue, that's a VLC issue.

[justcallmefrank]

Yep, pretty much what I'd thought. As far as I knew I was invoking them on the UI thread rather than the VLC thread though, as I had to to have my UI update with the track time event. I'll have to double-check my implementation, it was just a hack to get it up and running though.

Go VLC Thanks for the info.

[m.e]

Is it just me or was the old 0.8.6 API much better. One used to have access to both getvariable and setvariable. Using those methods you could get things like embedded subtitles and audio streams and you could set thing like brightness and contrast without having to restart the video. I'm not criticizing Kairos in anyway, the wrapper is well made and it wraps all the methods available in libvlc but I don't understand why these methods was removed from libvlc.

[Jean-Baptiste Kempf]

Is it just me or was the old 0.8.6 API much better. One used to have access to both getvariable and setvariable. Using those methods you could get things like embedded subtitles and audio streams and you could set thing like brightness and contrast without having to restart the video. I'm not criticizing Kairos in anyway, the wrapper is well made and it wraps all the methods available in libvlc but I don't understand why these methods was removed from libvlc.

Yes, and this introduced many many security and crashes issues.

Therefore, if you need some access to some internal of VLC, then write new functions for libvlc, as in 1.0.