Page 1 of 1
VLC via VLCJ
Posted: 06 Sep 2010 17:15
by claudeH
Hi
We are trying to use VLC (1.1.1) in a Java application (wrapped by using VLCJ).
Our application is delivered through java web start. Our Videos are all encoded with Theora and Vorbis.
1) As we do not want ask the end user to install VLC before being able to play video , we’d like to provide the DLLs within our application (Jar Embedded).
The first problem concerns an error message indicated by VLC about the parameter “plug in path” which seems required.
We’d like to avoid extracting all the needed DLLs from Jar to a local path. We have tried to force the loading of all DLLs programmatically but as the parameter is not defined that prevents VLC to work. Is there any way to achieve that?
2) As we use few codecs and that our application only works on Windows platforms, we’d like to deliver the required DLLs only (less than 10Mb). The current Plugins folder takes about 50Mb (268 files). How can we get the list of the DLLs really required?
Any ideas?
Re: VLC via VLCJ
Posted: 06 Sep 2010 17:39
by sherington
Maybe this can give you some ideas for #1:
http://stackoverflow.com/questions/1611 ... -dll-files
My understanding is that you do have to unpack the DLLs from the jar I'm afraid.
Re: VLC via VLCJ
Posted: 09 Sep 2010 10:16
by claudeH
HI
Thanks for your prompt answer.
In fact we'd like to use the upgrade process implemented by java web start as soon as some modules have been released. If we manage by yourself the DLLs extracting to a temporary folder we will have to test everytime that no changes concerns the VLC DLLs and to substitute the old files by the new ones. (not so complicated but that can be done without adding any more upgrading step....it's certainly better) the other reason is that the folder may be removed manually or by using a cleaning software such as CCleaner ...
By the way the most important and difficult thing to achieve is to determine what are the DLLs really required to play Video only encoded with theora and vorbis. As everybody has not a fast Internet access we would like to reduce as much as possible the number of DLLs to download. Anyway we do not see any interest to provide the others codecs we will never use.
Some DLLs also provides some methods to change the scale of a video or to apply some filters and even to manage different ways to play video. (file, http, ftp, etc.)
Is there anybody who could have this information?
Thanks
Re: VLC via VLCJ
Posted: 10 Sep 2010 02:12
by Rémi Denis-Courmont
I don't understand the question really. You need to check what each plugin does, and if you need it. There is no magic there.
Re: VLC via VLCJ
Posted: 10 Sep 2010 13:54
by claudeH
trying to get a simple list of the mandatory dll to make work VLC to play video only encoded with theora and vorbis is something magic...
There are 275 files in the folder plugins...
Sure that some DLLs are mandatory and others are not.
I do not think that my question needs any magic way or magic place to get answer above all for the developper whose have worked on the player.
Re: VLC via VLCJ
Posted: 10 Sep 2010 14:31
by Sébastien Escudier
This list doesn't exist, and we can't make one each time someone has a specific need.
Do you need to play video from file, from network... do you need to demux mp4 files etc... what type of video ouput do you want...
You have to figure it out yourself and make this list yourself.
Re: VLC via VLCJ
Posted: 10 Sep 2010 15:12
by claudeH
Hi
I have started to figure it out by myself. as the dll are not locked I have to rename each dll and check whether or not VLC is able to play the video. empiric way isnt'it?
The DLLs seems shared in different task groups:
- Codecs (Audio, Video)
- Filters
- Communication protocol,
- etc.
That's why I believed that asking the list of the minimal mandatory DLLs was not really something special.
By the way, VLC is a awesome product. Nice work!
Merci quand même.
Re: VLC via VLCJ
Posted: 10 Sep 2010 15:18
by Sébastien Escudier
you can have a look to modules/LIST (in the sources)
there's a short description of each.
Re: VLC via VLCJ
Posted: 27 May 2014 05:31
by pants
1) As we do not want ask the end user to install VLC before being able to play video , we’d like to provide the DLLs within our application (Jar Embedded).
The first problem concerns an error message indicated by VLC about the parameter “plug in path” which seems required.
We’d like to avoid extracting all the needed DLLs from Jar to a local path. We have tried to force the loading of all DLLs programmatically but as the parameter is not defined that prevents VLC to work. Is there any way to achieve that?
Sorry for reviving this long dead thread. I am hitting the same issue as claudeH above and I am trying to decide whether I should take the approach suggested by sherington or attempt to modify vlc to support loading the plugins from a jar. I am not a strong C developer but if the work is not too difficult and someone could point me in the right direction I would consider taking it on (launching directly from a native archive in JNLP is a much cleaner and more desirable solution than extracting the jar). Could someone with experience estimate how much work adding this functionality might be (~1 day, ~1 week, ~1 month)? To specify the problem more precisely, given a jar file with the following contents how difficult would it be to instruct vlc to load the plugins from within the archive:
axvlc.dll
axvlc.dll.manifest
COPYING.txt
libvlc.dll
libvlc.dll.manifest
libvlccore.dll
plugins/<plugin1>
plugins/<plugin2>
...
Thanks in advance for your time!
Re: VLC via VLCJ
Posted: 27 May 2014 10:09
by Rémi Denis-Courmont
You would need to rebuild LibVLC to use whatever adequate functions instead of dlopen/LoadLibrary and dlsym/GetProcAddress to access plugins. I am not sure that is even possible.
Re: VLC via VLCJ
Posted: 14 Jun 2014 22:06
by pants
How difficult/possible would it be to distribute libVLC and all of its plugins as a single dll such that it does not need to load any additional dynamically link libraries to be launched?
Re: VLC via VLCJ
Posted: 15 Jun 2014 08:55
by Rémi Denis-Courmont
Asking the question twice won't get any more satisfactory answers.