I updated my previous post. You’re not really connecting any parts in the code you provided: you create a buffer and never fill it, pushing it into the texture every frame and expecting a video will play when you draw it. You have misconceptions about OpenGL and I advice you to work on that first. Try to load your own (non-POT) texture, then you’ll see that glGenTextures() is not optional, and how there are many more calls to OpenGL required to set this up properly.
[quote]buffer not being filled
[/quote]
right here
buf = memory.getByteBuffer(0, 1280 * 544 * 4);
display(Memory) is getting called and memory filled by VLCJ itself
like here http://code.google.com/p/vlcj/wiki/JMonkeyEngineExample
Hm, okay, how are the buffer blits synced? You never request a new frame, and without any request, it must be running on another thread, which will cause lots of tearing as the buffer can be modified during upload.
yeah glGenTextures, ok, doing this, now. No change though.
IntBuffer tmp = createIntBuffer(1);
GL11.glGenTextures(tmp);
glTextureID = tmp.get(0);
public IntBuffer createIntBuffer(int size)
{
ByteBuffer temp = ByteBuffer.allocateDirect(4 * size);
temp.order(ByteOrder.nativeOrder());
return temp.asIntBuffer();
}
GL11.glBindTexture(GL11.GL_TEXTURE_2D, glTextureID);
Yeah no idea. Looking at the JME example it says “Synchronisation might be required…”
I assumed frames were requested by time automatically, because there aren’t any calls in the JME example for this.
But yeah tearing and sync… well first I need it to display anything.
I uploaded an eclipse project, so people who wanna help can actually try.
http://www.mediafire.com/?m3eloau579blx13
This project contains everything you need, but only works on windows (only has the vlc dlls).
You dont need VLC installed or anything like that. A Video to test with is also contained.
TO run the LWJGL class just use the vm parameter “-Djava.library.path=lib” (if my configurations dont show up)
You can also use
public static void main(String[] args) {
System.setProperty("org.lwjgl.librarypath",System.getProperty("user.dir") + "/relative/path/to/root/of/natives/");
....
}
This is a not well known LWJGL hidden switch that lets you bypass the -Djava.library.path option.
Ugh… can’t seem to get this on my MacOSX. Keeps giving me “[0x100150020] main libvlc error: No plugins found! Check your VLC installation.” even though I am using the proper VLC_PLUGIN_PATH variable for my VLC version… ???
Just read. I told you, only windows.
Adding the Linux .so files would be best I could do
No access to a mac anyway
Nah, I’ve been trying to get it working using the JARs from the VLCJ/JNA website – not your eclipse package. After some tweaking I got it to link with my VLC libraries (vlclib/vlccore) but I’ve hit a roadblock with the plugins problem.
I dont even know what “VLC_PLUGIN_PATH” is =D
I just set the JNA lib path in my source, to a local vlc copy
they want you to install it like normal, then link to it using this global variable and shit
but I just copied a private copy of what we need here
The woe of using native code 
Cas 
yes, well, we are outta options
but once someone with OpenGL skill can make it work, its a theora player that works great
I know OpenGL. Give me a buffer with frame data and I’ll put it on screen.
why not use https://github.com/pirelenito/MovieGL
seems like a solid opengl movie player based on JMF, I know that this doesn’t support many formats, but there a plugins for it like jffmpg(instead of fobs, what is suggested by this project).
One wouldn’T have any natives libs, what would be great.
I was hoping you would show up.
well knock yourself out, that eclipse project should run
the jme example is there, I’m sure you can get this to work
I knew it would =)
Great !
Well, if you give me a ByteBuffer containing perfectly formatted RGB data and tell me to display it with OpenGL…
The code is pretty stupid, it just uploads the data every single frame instead of only when it changes, but it should get you going.
hmm … yeah … that doesn’t sound exactly legit! 
Luckily, you missed out the important news of the month. libVLC 2.0 is now LGPL. Just need to convince the developer of VLCJ to follow suit …
Slightly OT - I’ve finally got around to looking at forking out the GSVideo code from Processing to enable bundling of GStreamer binaries, so that’ll be another LGPL solution. I was almost not going to bother since it’s pretty easy to install a system version on Linux and Windows, but Mac on the other hand is a PITA. I’m also considering VLC as a backup video lib in Praxis.
One way to handle that might be to fork the code for DefaultDirectMediaPlayer, use two native buffers, and swap between them using the lock/unlock callbacks. That way you can let VLC get on with writing to one buffer while you make use of the other.
I don’t know why you are all struggling so much when bobjob already made a video player applet that just runs the ffmpeg exectuable in the background and reads its data from an InputStream… :