I also ran into this exception when trying to resize my 1080p video. It seems to happen erratically. And occasionally when closing I get this exception.

I can confirm that this exception happens. I played the video in fullscreen and tabbed out. This freezes the rendering, and when I tabbed in again it crashed with that same exception. It's most likely occurs when some video buffer is completely filled, probably since your computer didn't manage to display them fast enough.

I recommend ARB_timer_query. Easy to use and you get very accurate timings.

For trivial rendering (like this video player) you just need to be careful with reading back the times. It will cause a pipeline flush and will skew the rest of the rendering, like SwapBuffers does to the texture update above. A trick I use is to actually measure every X frames, where X is how many frames it takes for the timing result to be available. Like so:

At 1080p it runs at 20 FPS and audio goes out of sync. (receiving 20ms, rendering 80ms)

The video player doesn't drop frames. If rendering takes 80ms, you'd only ever get 12.5fps, which is not acceptable in the first place. That is goes out of sync is no surprise, given that the video can never 'catch up'.

I also ran into this exception when trying to resize my 1080p video. It seems to happen erratically. And occasionally when closing I get this exception.

Regarding exception #1, that's not supposed to happen anymore in the latest versions. I tested whether a buffer put in the pool returned true for obj1.equals(obj2) on any item already in the pool. For distinct ByteBuffers containing the same pixels, this returned true. Now I'm using '==' instead. Which version (of the jars) did you use?

Regarding exception #2, that happened when ffmpeg.stdout returned an incomplete frame, which basically happens because I close the stream during closing of the player. I simply removed rethrowing the IOException as IllegalStateException.

I can confirm that this exception happens. I played the video in fullscreen and tabbed out. This freezes the rendering, and when I tabbed in again it crashed with that same exception. It's most likely occurs when some video buffer is completely filled, probably since your computer didn't manage to display them fast enough.

This shouldn't be the cause of that exception, really. I cannot reproduce it, so I hope that my latest version solves it.

Version 0.7.11 of YUNPM

Re-enabled measuring of PBO performance, which allows fallback to plain texture updates, if the drivers pick an horrendous path. (previously reported by kappa, with ~330ms updates per frame)

Well, finally got a few hours to look at tidying up the GStreamer stuff today. I initially looked at creating an alternative backend to YUNPM, but due to the difference in approach (callback vs streaming) this was leading to about 4x more code then was actually required (and I was having issues with some of the dependencies - seems a few things missing in your JAR?). So, instead we have GstLwjgl - in a separate thread so as not to pollute this one further! Not quite as CPU friendly yet (not too bad), but it is lacking a few optimizations.

The video player doesn't drop frames. If rendering takes 80ms, you'd only ever get 12.5fps, which is not acceptable in the first place. That is goes out of sync is no surprise, given that the video can never 'catch up'.

Given our earlier comments on sync, isn't the lack of frame-drop actually a bit of a flaw at the moment? Obviously, constant frame dropping will look terrible, but the ability to always work to the audio clock and drop the odd video frame (in case of CPU spike, etc.) would seem to be important for accurate sync - unless I'm missing something in your answer?

I own a flower shop and every wednesday a friendly guy comes in, handing out flyers for his flower shop. I offer him tea and a biscuit and we discuss unrelated business.

LOL - nice analogy! Actually, you misinterpret my intentions though. I have no interest in running a flower shop, I have enough other shops to juggle at the moment! One flower shop would be fine in this town, but I disagree with growing half the product in the back garden when a reputed wholesaler can offer so much more with far less effort. Ah, you say, but I can never get hold of that wholesaler, the phone always seems to be down .. here, try the number on this card instead!

You started this thread with the assertion that there was no useful code for video in Java. As I've pointed out before, there are lots of people away from here quite happily working with video, and have been doing for years (Processing guys particularly have this all working cross-platform). Almost all are using GStreamer, some are using VLC. Most of the code I posted above was on here months ago, and it's a far simpler too. Use it or ignore it, I don't particularly care - I'll maintain it because I personally need the extra features in Praxis. Just don't see the point in re-inventing the wheel! I personally believe that a marriage of GStreamer backend and the YUNPM rendering code is the best way forward, and while working now also offers some interesting longer term potential (hardware decoding and rendering directly to texture, streaming video from the net, etc.) If a shotgun wedding ain't the way forward, then so be it.

@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 on Slackware

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).

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.

</rant>

<rant>Seriously!</rant>

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

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.

because the GStreamer developers couldn't be bothered to make their shit work?

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.

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?).

Guess why I shipped the binaries... because I try to make it work for everybody, regardless of their choices.

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.

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

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.

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.

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!

You seriously suggesting that it's down to library developers to support every Linux based OS?

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"

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.

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).

The video player doesn't drop frames. If rendering takes 80ms, you'd only ever get 12.5fps, which is not acceptable in the first place. That is goes out of sync is no surprise, given that the video can never 'catch up'.

Given our earlier comments on sync, isn't the lack of frame-drop actually a bit of a flaw at the moment? Obviously, constant frame dropping will look terrible, but the ability to always work to the audio clock and drop the odd video frame (in case of CPU spike, etc.) would seem to be important for accurate sync - unless I'm missing something in your answer?

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.

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.

I have no special talents. I am only passionately curious.--Albert Einstein

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.

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.

I have no special talents. I am only passionately curious.--Albert Einstein

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