@nsigma
And yet the Gstreamer option is not working with the same its your config that is at fault from the coders! Gstreamer is continuing to live up to its reputation. Its crap and flaky.
In my book, that is not working. I should not need to spend half a day configuring anything to play movies with sound in a java app. More so if i can play movies from other applications just fine.
Be fair and mention what system you’re working with! It’s mainly meant to be a demonstration of library bundling for Windows. Easy enough to take the same approach on any other OS to give you a known quantity (I’ve never had issues on any Linux distro - that’s a distro issue not a GStreamer one, and a good reason in my book for choosing which Linux OS’s you support).
The end user is never at fault, mkay? Did you realize you suggested the end user to pick another OS distro, because the GStreamer developers couldn’t be bothered to make their shit work? For the sake of cute fluffy bunnies, please make more sense.
:emo:
Seriously!Ladies and gentlemen - Linux! Let’s give it a big warm hand.
Yes!
You seriously suggesting that it’s down to library developers to support every Linux based OS? That’s a distro’s packaging responsibility. That developers target a core number of popular Linux distributions is good and realistic IMO (and I’ve said that many times before here). It’s not a surprise that Valve and Unity3D are both only targeting one (Ubuntu).
If you’d not provided a binary of FFMPEG for Linux, you’d suffer with the same issues of differing distro’s - delt0r might have been OK, but others may not. It’s a good argument for bundling natives - my post was meant as a demo of this on Windows (which is most people here, yes?). The code could be adapted to do it on all 3 OS’s with minimal effort.
Guess why I shipped the binaries… because I try to make it work for everybody, regardless of their choices.
[quote=“nsigma,post:105,topic:39517”]
Any code could easily be adapted to do anything. Until it actually is adapted, it doesn’t matter to the end user.
Did you see how much effort I put in updating YUNPM, to make it work for everybody? I even wrote a fallback to disable PBOs, when poor performance is measured, specially for kappa. I could have told him to use another OS distro, update his graphics drivers or explain to him how he could remove the PBO code.
It isn’t enough to dump code into the community. You have to support and maintain it for it to get anywhere. I put far more hours into this can I anticipated, but at least now people can embed video playback in their game and/or app.
Btw, kappa, could you post some info on your setup (OS/GPU/drivers/etc)? Maybe there’s a better solution to simply disabling PBO. Or at least we could detect the problematic environment without benchmarking, which is inherently sensitive to external factors.
[quote=“Riven,post:106,topic:39517”]
Actually, I un-adapted it from the Processing code (at least for OSX) because I didn’t have a way to test it.
Absolutely, and simply put I’m maintaining and supporting enough right now. I don’t under-appreciate the amount of time this has taken you - it’s great! I think one of the underlying choices you’ve made is wrong, and will make this far harder and time consuming to support in the long run. It doesn’t mean I don’t appreciate how important it is to this community that someone has stepped up to the plate.
Shipping binaries that work is a great thing - some LGPL binaries would be good too though! 
At least be specific. You’ve done enough vague handwaving over issues with YUNPM.
I agree with Riven that users aren’t at fault, obviously it just has to work.
Either you say “this game/app works with linux.” period. then you do everything you can to make sure it will work on every distro. Or you will only support specific Distros like “Works on Windows, Mac and Ubuntu & Mint”
Yeah, this was not a linux ready version, completely relying on preinstalled gst…
Only reason why I wouldn’t use it right now - I dont want to get sued.
So maybe someone can build binaries with only the LGPL codecs like theora and vorbis…
As YUNPM does not link ffmpeg, it is not a derived work, which (to my knowledge) means that YUNPM is not tainted by LGPL or GPL.
eeeh right :clue:, well shipping codecs which are licensed isnt ok - thats as far as my knowledge goes
Agreed the current detection method isn’t the ideal way to go. PBO’s work perfectly on my home computer however the computer I was testing on (Windows XP, Java 7) has an ATI Radeon Xpress 200 series card, it uses the latest drivers available for it from ATI/AMD (Catalyst 10.2).
The card does claim to support OpenGL 2.1 and PBO’s however I’m pretty sure the driver/card is borked in some way. I’ve noticed that some types of GLSL fragment shaders fail to compile for unknown reasons (I’m guessing some hardware limitation) and the card also seems to be blacklisted by Firefox WebGL.
As for the YUNPM it works fine without PBO’s but has serious lag (sometimes even a blackscreen) when using PBO’s.
Not sure what the correct fix would be for cards like this, maybe we need to go the WebGL route and have a small library that maintains a blacklist of features for certain cards and drivers (maybe even copy the WebGL list).
This, for one.
Trying to rewrite A/V sync from scratch rather than relying on an available solution, is IMO going to end up being a headache. I’m also assuming that using separate processes makes it harder to control / skip frames through FFMPEG.
Actually, thought of this just after I posted - think you’re right and OK with that one. Permission to ship h264 is another thing, though, so at least an LGPL build would remove it.
Shipping H264 has nothing to do with GPL or LGPL… its a patent issue. Countries that respect software patents it is a patent violation to ship it. Its less clear about other parts of a license agreement with MPEG-LA is really enforceable in some countries. For example you also need a license to ship content in H264 according to MPEG-LA and you must agree to that to get a license from them for the encoders/decoders.
There are many other details, but long story short, its easier to just not include it. This is not a big deal in the bigger scheme of things. Theora is pretty good now, and more than good enough for government work.
I just like the idea that adding a intro movie and/or a info video is now a possibility.
WRT H264…hardware decoders on embedded devices is one reason to go that route.
I would expect that the local OS/hardware can then provide a licensed decode path in that case. OpenMax was/is suppose to make accessing this fairly easy… in theory.
Jesus Christ, what a hurdle. How bad is Theora anyway?
It’s great.
Theora quality for quality is pretty similar at high bit rates (at least most folk can’t tell), at lower bitrates (aka not DVD or BluRay bit rates) assume about 1.5 increase in bit rate tops for the same quality. I am being conservative and of course the content makes a big difference. It should also be pointed out that its the h264 encoder that is pretty impressive. If theora had that much work put into its encoder, how good would it be? Well we don’t know, but it could be more competitive.
Theora also is less complicated to decode. So cpu usage should be less for software decodes.
However even though theora never will win the codec wars, the mere existence of a license free codec has been worth its weight in gold. At the very least it keeps the others honest.