Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (536)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2 3
  ignore  |  Print  
  is video playback in java really as complicated as it seems?  (Read 9584 times)
0 Members and 1 Guest are viewing this topic.
Offline h3ckboy

JGO Coder


Medals: 5



« Posted 2011-12-15 18:45:11 »

Hey, I am looking to add a little bit of video playback (a video playing in the background of my menu), and the more I read as I google/search forums, the more impossible the task seems.

First there is JMF, quickly found out that that sux. then I stumbled across a couple of things, and then on to someone saying that they extracted JMC fromt he javafx, but that seems strangely difficult, and someone mentioned problems.

so if anyone knows any actually practical ways, that would be fantastic Smiley. BTW, this is an applet if that matters.

Thanks,
h3ckboy
Offline theagentd
« Reply #1 - Posted 2011-12-15 18:53:09 »

This thread has some info: http://www.java-gaming.org/topics/vlcj-in-opengl-lwjgl/24846/view/topicseen.html.

Myomyomyo.
Offline h3ckboy

JGO Coder


Medals: 5



« Reply #2 - Posted 2011-12-15 20:55:00 »

hey, thanks for the fast reply. A quick read and I just have one question, does it require signing? cuase I saw mention of it. I would prefer to find a way to do it without signing because I have actaully gone through a lot of trouble to avoid that.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 744
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #3 - Posted 2011-12-15 20:58:26 »

If neither bandwidth/filesize, CPU-usage and image-quality are a major concern... why not try MJPEG? Wink

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline theagentd
« Reply #4 - Posted 2011-12-15 21:35:36 »

If neither bandwidth/filesize, CPU-usage and image-quality are a major concern... why not try MJPEG? Wink
And here I thought compression, performance and quality was a "pick two of three" thing of video compression...

Myomyomyo.
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 744
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #5 - Posted 2011-12-15 21:37:36 »

If neither bandwidth/filesize, CPU-usage and image-quality are a major concern... why not try MJPEG? Wink
And here I thought compression, performance and quality was a "pick two of three" thing of video compression...
Yeah, I had that exact same thought... "pick one of three" seems really awful, but it's trivial to implement, works everywhere and well, that's basically it.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline gouessej
« Reply #6 - Posted 2011-12-15 21:44:03 »

hey, thanks for the fast reply. A quick read and I just have one question, does it require signing? cuase I saw mention of it. I would prefer to find a way to do it without signing because I have actaully gone through a lot of trouble to avoid that.
Yes it often requires signing, maybe look at Curtado. Video playback often requires the use of native libraries  Sad and you cannot use them without some permissions.

Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #7 - Posted 2011-12-15 21:56:34 »

MJPEG's not a bad solution to begin with though it uses something like 10x the space of nicely compressed H264. You'll also have to interleave your audio with it manually I think.
Xuggle works, but it's large (5mb or so last time I looked?) and uses native code. Cortado I did at one point have working ... a bit. But it was riddled with bugs, and almost no video I compressed would actually play back under it. This was about a year ago. It also needed quite extensive modification to get it to play back into OpenAL and OpenGL.

Cas Smiley

Offline Riven
« League of Dukes »

JGO Overlord


Medals: 744
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #8 - Posted 2011-12-15 22:01:06 »

MJPEG's not a bad solution to begin with though it uses something like 10x the space of nicely compressed H264. You'll also have to interleave your audio with it manually I think.
Xuggle works, but it's large (5mb or so last time I looked?) and uses native code. Cortado I did at one point have working ... a bit. But it was riddled with bugs, and almost no video I compressed would actually play back under it. This was about a year ago. It also needed quite extensive modification to get it to play back into OpenAL and OpenGL.
Last time I checked it was more like factor 2-3 than factor 10. So it's not that bad... and you don't have to sign anything.

I have no idea why I'm defending MJPEG Smiley

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #9 - Posted 2011-12-15 22:10:11 »

Heh Smiley Well, it is arguably the simplest and easiest way to do it, especially if you're talking about under a minute of 15fps low-res video footage and broadband downloading.

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Mike

JGO Ninja


Medals: 71
Projects: 1
Exp: 5 years


Java guru wanabee


« Reply #10 - Posted 2011-12-15 22:12:49 »

I have no idea why I'm defending MJPEG Smiley


My current game, Minecraft meets Farmville and goes online Smiley
State of Fortune | Discussion thread @ JGO
Offline ra4king

JGO Kernel


Medals: 337
Projects: 2
Exp: 5 years


I'm the King!


« Reply #11 - Posted 2011-12-15 23:19:20 »

Well on decent computers, extracting each frame and drawing it on a BufferedImage shouldn't be that slow Tongue

Offline theagentd
« Reply #12 - Posted 2011-12-15 23:19:42 »

Inadequate. Needs more JPEG compression artifacts.

Myomyomyo.
Offline h3ckboy

JGO Coder


Medals: 5



« Reply #13 - Posted 2011-12-16 07:53:59 »

@ra4king, yeah those were my thoughts exactly.
Offline h3ckboy

JGO Coder


Medals: 5



« Reply #14 - Posted 2011-12-16 07:55:58 »

for MJPEG, would something like this:
http://www.walking-productions.com/notslop/2010/04/20/motion-jpeg-in-flash-and-java/
be a good way to do it?
Offline bobjob

JGO Knight


Medals: 10
Projects: 4


David Aaron Muhar


« Reply #15 - Posted 2011-12-16 08:21:45 »

I made a video player a while back using ffmpeg (link)
It wasnt the best didnt really spend much time on it. But it might be a good idea to look into ffmpeg command line tool.
you can feed any video compression type out to jpeg over a socket (aswell as .au for sun audio). And just have a server waiting to upload any images or audio data.
On stopping the video you can simply close the port, and ffmpeg will close.
you can also set a whole bunch of custom settings into the command line tool, also read the video information with the ffmpeg output.
It would also mean that it would automatically updated with any new release of ffmpeg.
The bottle neck is weather or not FFMPEG real time encoding is fast enough. That said, even if the computer isnt fast enough you can always change the export screensize, or framerate so that even the slowest computers can view something.

My Projects
Games, Webcam chat, Video screencast, PDF tools.

Javagaming.org with chat room
Offline Cero
« Reply #16 - Posted 2011-12-17 05:07:10 »

yeah I made many threads about this, and eventually no have given up
we are doing cut-scenes, graphic novel style

list of problems:
- almost all codes cannot be used due to licensing, gotta use something like theora
- audio & video syncing
- the code to playback
- most video playback code has some license by itself. "if you want to distribute vlc, then your own code must be GPL, meaning you will need to offer your own game source code" (Mark Lee, VLCJ)
- if you want to support all 3 major platforms, the video code should also work the same on every platform - seems almost impossible to achieve
- you have to ship codecs and stuff, because you can obviously never expect the user to have something installed - again legal issues with that
- linking problems and stuff
- most video libs are for use in swing, not OpenGL (which makes it at least hard to port them, into your OpenGL game in a decent manner)

facts:
- I personally know of no java game, which runs on all 3 platforms and has video playback (of course I might be wrong, but its definitely not common)
- even Xuggler, which is quality-wise the best, has no player, and still syncing problems
- jMonkeyEngine scrapped video playback

I would kill for BinkVideo-Java

In short: There is no practical way of implementing video into a java OpenGL, cross platform game today; at least none that is "known" or published

other threads by me on this problem:
Video Playback
VLCJ
gStreamer

Offline nsigma
« Reply #17 - Posted 2011-12-17 19:08:13 »

@Cero  So, how did you get on with GStreamer in the end?  I've worked with this in Praxis on Linux and some testing on Windows, and it seems to work well with a system installed GStreamer (from OSSBuild).  You can also ship the library alongside your code too.  GStreamer will be the default video library in the forthcoming version of Processing, and they have the Windows and Mac native libs packaged in their repository (http://code.google.com/p/processing/).  It would seem to answer a lot of your list of problems - it's LGPL for a start, and it is possible to get the data directly into an OpenGL texture.  It's obviously not a good solution for an applet, and it's rather large, but for a desktop based game it should be usable.  You can pare the size down by only including the minimal codecs you require (which obviously has to be something you can ship).  With the Processing guys pushing it, it's likely to get a lot of cross-platform focus on it as well, and extracting their work to pure Java shouldn't be too difficult.

Best wishes, Neil

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline Cero
« Reply #18 - Posted 2011-12-17 19:19:02 »

So, how did you get on with GStreamer in the end?

Linking issues, I could never get it to run, always different errors.
One of my teams programmers tried too, and couldnt get it running aswell
out consensus was that if we developers can't even get it working, how likely is it to run for all users without problems ?


Quote
You can With the Processing guys pushing it, it's likely to get a lot of cross-platform focus on it
true that.

I just can't do all the work leading up to a practical, cross platform, java OpenGL videoLib

Offline Riven
« League of Dukes »

JGO Overlord


Medals: 744
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #19 - Posted 2011-12-17 19:22:59 »

I just can't do all the work leading up to a practical, cross platform, java OpenGL videoLib
Clearly it's important to you. I can't help but wonder why you didn't write a 10-liner mjpeg client.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline Cero
« Reply #20 - Posted 2011-12-17 19:37:08 »

I just can't do all the work leading up to a practical, cross platform, java OpenGL videoLib
Clearly it's important to you. I can't help but wonder why you didn't write a 10-liner mjpeg client.

right of the bat, I wouldn't assume that it would be fast and/or efficient enough

Quote
If neither bandwidth/filesize, CPU-usage and image-quality are a major concern... why not try MJPEG?

We have low system requirements, as in netbooks.
Also quality is an issue

by video playback - I'm talking about 1-5 minute, 720p videos, obviously without artifacts

haven't really looked into MJPEG

only used some JPEG format with jmf back then

Offline theagentd
« Reply #21 - Posted 2011-12-17 19:48:03 »

We need someone to write a multithreaded, standard compliant H264 decoder in pure Java. Any volunteers?

Myomyomyo.
Offline Cero
« Reply #22 - Posted 2011-12-17 19:52:30 »

pretty sure using H264 has also licensing problems
IIRC its only free for internet video and end users

Offline nsigma
« Reply #23 - Posted 2011-12-17 20:20:43 »

pretty sure using H264 has also licensing problems
IIRC its only free for internet video and end users

WebM / VP8 might be a better choice in that regard.  There seem to be a couple of attempts at pure-Java decoders out there (and I mean attempts from what I've seen so far!  Wink )

On the GStreamer linking thing - I installed the Windows OSSBuild version and it all just worked first time with Praxis, though I haven't given it a huge amount of testing yet.  Have you actually tried with Processing to see if their bundling of the native libs works?

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline Cero
« Reply #24 - Posted 2011-12-17 20:30:53 »

pretty sure using H264 has also licensing problems
IIRC its only free for internet video and end users

WebM / VP8 might be a better choice in that regard.  There seem to be a couple of attempts at pure-Java decoders out there (and I mean attempts from what I've seen so far!  Wink )

On the GStreamer linking thing - I installed the Windows OSSBuild version and it all just worked first time with Praxis, though I haven't given it a huge amount of testing yet.  Have you actually tried with Processing to see if their bundling of the native libs works?

you seem to have a better hang of gStreamer - try and do a lwjgl package with everything included that just works
I didn't use the processing libs and stuff , because I wasn't sure of the license in this regard (distributing a part of Processing in a commercial product ?)

Offline bobjob

JGO Knight


Medals: 10
Projects: 4


David Aaron Muhar


« Reply #25 - Posted 2011-12-17 20:59:48 »

We need someone to write a multithreaded, standard compliant H264 decoder in pure Java. Any volunteers?
My FFMPEG player can  run any codec that ffmpeg supports. You can simple compile FFMPEG on any platform that you want to run the player on.

pretty sure using H264 has also licensing problems
IIRC its only free for internet video and end users
There are ways to get around licensing issues with FFMPEG, even if that means requiring a simple external installer not packaged with your program.

My Projects
Games, Webcam chat, Video screencast, PDF tools.

Javagaming.org with chat room
Offline theagentd
« Reply #26 - Posted 2011-12-18 09:20:42 »

We need someone to write a multithreaded, standard compliant H264 decoder in pure Java. Any volunteers?
My FFMPEG player can  run any codec that ffmpeg supports. You can simple compile FFMPEG on any platform that you want to run the player on.

pretty sure using H264 has also licensing problems
IIRC its only free for internet video and end users
There are was to get around licensing issues with FFMPEG, even if that means requiring a simple external installer not packaged with your program.
http://fmj-sf.net/ffmpeg-java/getting_started.php ?

EDIT: or http://jffmpeg.sourceforge.net/formats.html ? It even has MPEG 4 implemented in Java...

Myomyomyo.
Offline delt0r

JGO Knight


Medals: 26
Exp: 18 years


Computers can do that?


« Reply #27 - Posted 2011-12-18 10:34:36 »

I have had a chat with a lawyer on the licensing thing. First off outside the US and the odd other country that has software patents using a software version of something like H.264 is, to the letter of the law, is possibly ok. That is right, even then the lawyer would claim its ok if you are making money. The the only thing that is free with H.264 is streaming over the web, the encoder and decoders need a license if you ask MPEG-LA. 

As for quality and space, well its no secrete that MJPEG sux on this front, but if you don't have a lot of cut scenes it may be a good option.

But don't buy the H264 is the best by far crap. I was on the doom forums and i pointed out that at the kind of bit rates I care about (high quality) MEPG2, H264 and Theora are about the same for 99.9% of the people out there. The answers i got is we need to use really low and unrealistic bit rates so we can tell what is better! IMO that is crazy talk. 

Theora does not have hardware decoding but recent versions do 1080p on my old machine with less that 30% of one core.

So the best option IMO is a JNI to the standard Theora playback libs with playback via lwjgl to solve or mitigate sync issues. Perhaps some thought as to how to get the data out.. ie perhaps decode directly to texture, and use GLSL for colour space changes, since this is often the bottle neck. Then basically use a build stack like lwjgl uses. Some work, but the lest work IMO... 

I have a GLSL codec of my own which in tests didn't do so bad, but i doubt i will finish it on a human time scale Cheesy

I have no special talents. I am only passionately curious.--Albert Einstein
Offline nsigma
« Reply #28 - Posted 2011-12-18 13:08:21 »

you seem to have a better hang of gStreamer - try and do a lwjgl package with everything included that just works

Firstly, I don't see the point of LWJGL in there at all.  What we need is a pure-Java equivalent / fork of GSVideo from Processing.  Once you can get to the stage of having access to the native video buffer, you can do what you want with it.

I'm on the GStreamer-Java mailing list, as is the author of GSVideo, so I'll see if there's any possibility of him doing it.  If not, then I might look at forking it myself, but it's not going to happen in the short term - too much other stuff on right now.

I didn't use the processing libs and stuff , because I wasn't sure of the license in this regard (distributing a part of Processing in a commercial product ?)

Processing core is LGPL, same as GStreamer.  If you can ship with one you can ship with the other!

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline delt0r

JGO Knight


Medals: 26
Exp: 18 years


Computers can do that?


« Reply #29 - Posted 2011-12-18 13:51:47 »

I say lwjgl because everything java2d is *not* easy to sync if at all. To sync you going to need to framedrop sometimes which looks horrible on PC monitors where you really need to run a native frame rates or have a very consistent pull down. Now lets consider java sound? Hell no, just use openal. Java2d is just not animation friendly.

BTW you should always sync to sound rather than a clock if possible. Perhaps not so important with short clips, but for long ones, the pc timers are not accurate, so sync with what we humans notice... sound out of sync with video.

I have no special talents. I am only passionately curious.--Albert Einstein
Pages: [1] 2 3
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Riven (12 views)
2014-07-29 18:09:19

Riven (8 views)
2014-07-29 18:08:52

Dwinin (9 views)
2014-07-29 10:59:34

E.R. Fleming (26 views)
2014-07-29 03:07:13

E.R. Fleming (10 views)
2014-07-29 03:06:25

pw (39 views)
2014-07-24 01:59:36

Riven (39 views)
2014-07-23 21:16:32

Riven (27 views)
2014-07-23 21:07:15

Riven (28 views)
2014-07-23 20:56:16

ctomni231 (59 views)
2014-07-18 06:55:21
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!