Well, I don't need it quite that soon! However, I do need to be doing some stuff with applet video in the next couple of months. My plan was actually to look at marrying Cortado with PulpCore (PulpCoretado anyone?) to build an applet video player that works and also doesn't look shit! Marry those two together and I reckon it would be possible to get an experience close to some of the Flash video players. I'm not bothered about the GPL licence if it's applet based (it's not like it's AGPL anyway), however a more liberal licence would be better.

Incidentally, all of the GPL code in Cortado seems to be an old port of GStreamer objects - and GStreamer is LGPL - aargh! Might be worth getting in touch with the GStreamer team rather than Xiph about relicensing - it was done by one of the same developers. Otherwise, I wonder how easy it would be to reimplement the interfaces based on the C code ... hmm

@cas JMF? Yuck! The joy of stepping around the weeping entrails of barely breathing Java API's. When native libraries are an option (and usually is for the stuff I do), I've been using the Gstreamer-Java bindings which seem to work pretty well. Depends obviously on having GStreamer installed but this is (allegedly!) cross-platform these days. It also uses JNA which I'm rapidly becoming very fond of.

I'm more thinking along the lines of, hack the crap out of Cortado, and distribute the resulting .jar along with my game, so I can play video through it. I'm not bothered about releasing the source of my games (most of the code is already open sourced) but I am bothered with actually having to put any effort into providing the source. But if the GPL only covers the jar file then that'll be fine because I'll have it all in sourceforge anyway.

In that case I'm going to butcher Cortado so thoroughly unrecognisably no-one else will want to use it. Well not much. I have very narrow requirements (although I expect that those narrow requirements will be of use to 99% of the people in here who want them - "I want to play video into OpenGL and audio into OpenAL")

<edit>They really didn't quite grasp Java when it came to the GPL did they.

if you do use *any* GPL code in your project (and you distribute it) - then all of the code that uses that library must also be GPL.APLG is basically the same - except it requires you to GPL your code - regardless of the actual distribution.

If the library is LGPL, then only the distributed library - and any changes - needs to be LGPL'ed.(technically, there are issues with obfuscating LGPL libs too - but thats another issue for another day)

I've just had another look through the Cortado code to search through the licence headers. Seems there's a lot less GPL code in there than I thought, although it's all a mess. I'd assumed it was licensed package by package but no such luck. Bizarrely, most of the GPL stuff is not actually code - it's interfaces, abstract classes and the odd data handler - mostly API. All the actual meat of running the audio and video pipelines is LGPL. There's even weird things like Clock being an abstract GPL class, but being implemented by an LGPL subclass (AudioSink)! OK, so we extrapolate the interface from the concrete class and replace the GPL code - what a waste of time!

@cas I must be in the 1% then, as I don't want to use it with OpenGL. However, either way will involve getting the raw data out into a buffer in some usable form.

I know what you mean - both the irksome-ness and being guilty of exactly the same thing, though I think even I manage slightly better than this!

Anyway, try having a look at the GStreamer documentation - it should get you around the terminology and architecture fairly well. I kind of understand the architecture of Cortado having worked with GStreamer a lot recently.

I agree with Neil. I don't understand the licensing logic in Cortado, neither. Most of the LGPL classes have references to GPL classes, so you cannot use the LGPL part without licensing the whole as GPL. Of course, everybody is free to license its code with the license he/she chooses, and then if you don't like it you are free not to use it. Mi intention is to use the LGPL part the best way I can without even looking at the GPL part (if you look at the GPL part you can "contaminate" the LGPL part).

As Neil suggests, one can translate the C version of GStreamer into Java. In fact, the package com.fluendo.jst (which has many GPL classes) is based on GStreamer. Rewriting these classes is a lot of work, but it would be perfect because we could use the com.fluendo.plugins package that has classes for audio, video and subtitles.

I am not an expert of GStreamer, but so far I understood that is made of plugins that you can connect in a pipeline. For example, you have an HttpSrc (the source that reads the file) connected to a TheoraDec (the theora decoder) and this connected to the VideoSink, the display. There are other plugins like VorbisDec and AudioSinks for the audio part. I think that the jst package has classes for the connection between plugins, but the important part is in the plugins (which fortunately are LGPL). For Pogg, I use these plugin classes removing the references to GPL classes (this is in my pogg.plugin package).

Looking at VorbisDec you may understand how to use the jorbis package to extract the audio part. Then AudioSink, AudioSinkJA and AudioSinkJ2 will help to use the javax.sound package to play it.

I don't have much time these days, but if you make any advances I'll be interested.

I really like the LGPL licensing as it let user freedom of closed their sources, too bad to not be able to use cortado, It would have help me a lot for a comercial project we just got, but theire is no way of redistribute our selled source code, this is just stupid as we cant sell it to our customer while letting source code for free for everybody....

so.... if only sound is missing in Pogg that maybe a good solution and I will probably see if I can give any help on it too in some weeks.

IMO throwing out all of the jst package is a mistake. Most of the classes that actually do anything useful in here are LGPL already. Coupled with that, the public API shouldn't be restricted by GPL, only the implementation of it. This means that public methods and fields should be fair game - it's not like they can't be worked out from the LGPL code anyway! Then it's just re-implementing what's left, and that isn't much - a lot of the methods are getters and setters, and the rest are fairly obvious things like peek(), poll(), put() etc. Anything that's not obvious could be checked against the same function in either GStreamer itself, or the GStreamer-Java bindings.

I'm happy to put some work into this, but can't do it for a few weeks. Also, I wouldn't necessarily fit your cleanroom requirements! Personally I wouldn't worry too much about the contamination thing, as long as we don't copy the exact implementation. I'd guess Fluendo's intention was for all of the jst and plugins package to be LGPL anyway, otherwise why release subclasses with a more liberal licence - given that it's one company I call that implicit permission!

I think you guys are mistaken, only the applet-player is under GPL.. the theora decoder is under LGPL, look here:

Quote

jheora is part of the Cortado streaming applet available from here. And while the Cortado applet is GPL, jheora is LGPL

Although it's impressive, I was able to play full-speed 720p MPEG4 video inside LWJGL, purely decoded with Java, but I dropped it MPEG4 is patent protected and you have to pay licensing fees to include a decoder with your game.

Momoko_Fan, would you mind telling me how you played back MP4 in pure java? Do you have the only pure Java MP4 codec in existence hidden away on your hard-drive? I'd sure like to get ahold of it if you do...

I think you guys are mistaken, only the applet-player is under GPL.. the theora decoder is under LGPL

I think you'll find we're not, since we're saying exactly the same thing! The theora decoder and the vorbis decoder are both LGPL. However, you need a framework to get these to work together and play in sync. In Cortado this is done by the jst and plugins packages - most, but not all, of which is LGPL.

Not at all. It annoys me when people use GPL for anything other than C/C++, because it's clearly designed for use with them.

I don't understand what annoys you here. Surely licensing is a decision for each coder based on personal and professional requirements. I have a variety of code in GPL, LGPL and other licences, depending on my needs, and none of it is in C or C++. I fail to see what makes the GPL more unsuitable for Java for instance. Yes, there seem to be various arguments around static and dynamic linking, but surely these affect C/C++ as well?

Momoko_Fan, would you mind telling me how you played back MP4 in pure java? Do you have the only pure Java MP4 codec in existence hidden away on your hard-drive? I'd sure like to get ahold of it if you do...

A pure Java MPEG4 codec is meant to be in the JFFMPEG project. That's just going off the website - never had a go!

Yep thats right. I got the MPEG4 codec from JFFMPEG, I made it not use JMF (I hate JMF! bloated piece of crap) and I optimized it a little bit here and there. For example I wrote a shader-based decoder for YV12 format, so you don't have to do colorspace conversion in java, but that only got a few fps.. The main bottleneck is in the iDCT which would have been very well optimized with SSE but in java it isn't Still playing 720p video on a single core with java is quite an achievement I think.

I don't understand what annoys you here. Surely licensing is a decision for each coder based on personal and professional requirements. I have a variety of code in GPL, LGPL and other licences, depending on my needs, and none of it is in C or C++. I fail to see what makes the GPL more unsuitable for Java for instance. Yes, there seem to be various arguments around static and dynamic linking, but surely these affect C/C++ as well?

It's a big minefield. AFAIC a licence should above all be clear, and since the GPL uses terms which have a fairly clear definition in the context of C (linking being the key one), don't have a clear definition in the context of Java, and are left undefined in the licence, it's not clear to me whether I can use a GPL library without contaminating my project.

In particular the most irksome feature of the GPL wrt Java is that using "class X extends Y" considers X to be a "derivative work" of Y. You could in theory work around this using composition and delegation but for the sake of a stupid OOP construct it's just daft.

There's no point in MPEG4, it's patented, you can't distribute your game in countries with software patents (United States for example) unless you pay licensing fees to MPEG-LA. My code doesn't do anything special, it just uses DivxDecoder in JFFMPEG except it's madly hacked to not use JMF. The YV12 hardware decoder like I said only gives a few extra fps which shouldn't matter IMO.

EDIT: Sorry if you want the source.. I don't have it anymore After I realized it's useless to me I wiped it out. If I can't distribute it freely then it was a waste of time. (J)Theora is a better bet, but last time I checked it was still using an old version of theora as base and isn't compatible with the latest features. I also tried Motion JPEG but it eats file space like crazy.

it's not clear to me whether I can use a GPL library without contaminating my project.

Seems clear to me. If you have any GPL code in the application classpath then the application has to be GPL. And this includes subclassing, delegation, composition, etc. The one circumstance that I can think of that becomes ambiguous is using reflection to let users dynamically link in libraries at runtime - depends how it's done I suppose.

I think "contaminating" is a real weasel word too. No one describes commercial software licensing in this way. Like I said in my previous post, I think it's for the author of the code, individual or company, to decide how to licence that code and what the cost of usage should be. If you're not prepared to pay the cost of using a commercial library then you find an alternative, and if you're not prepared to pay the "cost" of using a GPL library then you find an alternative. It's all economics at the end of the day, but then I've always been someone who links free software to free markets rather than some leftist conspiracy!

I think "contaminating" is a real weasel word too. No one describes commercial software licensing in this way.

its his opinion, there nothing wrong with being unique.but using a word like "weasel" is a personal attack, but i guess you just have an oposing opinion.edit: actually contaminating was a very accurate description in regards to his objective.

sry dont wanna stur up an patent/copywrite arguement, just chuckled when i was reading that.

Just wondering so If there was a pure java MP4 decoder I still couldnt distrube an intro movie, or cut scene with my game without paying someone?

There isn't and never will be - as Momoko_fan correctly pointed out it's not a freely licencable bit of code (though I do wonder of the validity of this in Europe - although that's moot anyway as software usually ends up getting distributed in the US). It doesn't bother me, personally, because my corporate masters will pay for licences.

Anyway... I'm hacking all the Cortado stuff out of Cortado, and just getting something really basic working. Eventually. I hope.

It still has a bad smell about it though; smacks of anonymous internet bitchiness. For which Wikipedia is famous. Still, don't reckon any offence was intended or taken eh? GPL is a pain in the arse for a lot of us, when loads of difficult stuff gets done and then it's essentially unusable because of the GPLs irritatingly altruistic restrictions. The main problem most of us face is that it's really impractical to release source code of everything into the wild, especially with dynamically runtime-linked code.

Quite! No offence was meant, and nor was it a personal attack (or anonymous internet bitchiness - "weasel words" might be described on Wikipedia, but it's quite a bit older!) If you think it was, please reread what I said. My opinion is also not directly opposed. I understand fully that GPL can be a PITA in certain circumstances, but so can commercial licences - they both have a price you need to pay.

I was only trying to defend the author's right to choose the right licence for them. While it may be frustrating and annoying to us (like in the Cortado case, to bring it back on topic!), I don't feel it's right to wilfully circumvent their wishes!

I think "contaminating" is a real weasel word too. No one describes commercial software licensing in this way.

Can you name a commercial software licence that works in the same way? They typically work on one of two bases: either you can use it but not distribute it; or you can distribute it, sometimes with fixed royalties per instance distributed. The most they're likely to insist I do with my own code is obfuscate the entire project.

Quote

Like I said in my previous post, I think it's for the author of the code, individual or company, to decide how to licence that code and what the cost of usage should be. If you're not prepared to pay the cost of using a commercial library then you find an alternative, and if you're not prepared to pay the "cost" of using a GPL library then you find an alternative.

I agree that you can licence your code how you want. Part of what I dislike about the GPL is that if you do (I will continue to use the word) contaminate your project by the way you use a GPL library then that choice is removed from you; the other thing I dislike is that it seems to me that the initial cost of using GPL libraries is hiring a lawyer in a foreign country to tell me what the rest of the cost is. Or, if I really want an answer I can rely on, waiting for a few lawsuits in California to define the terms. As it stands I don't know what the author's wishes are (or, at least, what a court would say they are).

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