Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed issue #650 persists when using JavaCV 1.3.3 jars #747

Closed
AmnonOwed opened this issue Jul 26, 2017 · 9 comments
Closed

Fixed issue #650 persists when using JavaCV 1.3.3 jars #747

AmnonOwed opened this issue Jul 26, 2017 · 9 comments

Comments

@AmnonOwed
Copy link
Contributor

AmnonOwed commented Jul 26, 2017

Issue #650 was fixed by pull #651.

I saw that JavaCV 1.3.3 was released yesterday, so after downloading it, I replaced the old jars by the new ones from the JavaCV 1.3.3 release. I expected that I would no longer need my CustomOpenCVFrameGrabber class, since the actual OpenCVFrameGrabber has now been changed according to the pull request.

Unfortunately when using the OpenCVFrameGrabber class from JavaCV 1.3.3 I still get the bad performance. When using the CustomOpenCVFrameGrabber I get good performance.

Thing I tried:

  • I doublechecked the source of OpenCVFrameGrabber in 1.3.3. which seems ok.
  • I doublechecked I was using the new jars (from 25-7-2017) and not the old ones.
  • To ensure the latest version was used, I removed the folder: C:\Users\username\javacpp\cache

I'm a bit puzzled why this is occurring...

Any thoughts?

@saudet
Copy link
Member

saudet commented Jul 27, 2017 via email

@AmnonOwed
Copy link
Contributor Author

Yeah, indeed. So if it's not this piece of code itself, what could possibly explain this behavior? Are there any other places where files are cached for this library?

I am using the library via a Processing sketch. My custom class is inside the Processing class (but relying on other parts of the JavaCV library), whereas the OpenCVFrameGrabber is inside the JavaCV library itself. Would this matter in any way, perhaps for the order of things?

@saudet
Copy link
Member

saudet commented Jul 31, 2017

Maybe some other of your dependencies are using an older version of JavaCV and overriding your choice?

@AmnonOwed
Copy link
Contributor Author

I've checked to ensure the latest and only the latest jars are used by the sketch (by renaming folders, dropping jars directly into the sketch folder etc.). This is definitely the case.

It's really strange! :) There shouldn't be a different outcome, but there is...

@saudet
Copy link
Member

saudet commented Sep 17, 2017

Any updates on this? Do you get the same issue with SNAPSHOT artifacts?

@AmnonOwed
Copy link
Contributor Author

No updates. Issue persists with latest Processing 3.3.6 and JavaCV 1.3.3.

It seems that with the OpenCVFrameGrabber class from JavaCV 1.3.3 the format is indeed set to MJPG (unlike with 1.3.2), however without the desired performance improvement. The custom class does give a performance boost. From the initial problem analysis we already found out that the order of things mattered for the performance improvement to occur. Perhaps when using the library there is a another interaction with OpenCV that somehow discards the setting or distorts the working order or something? Or maybe there are static/shared variables that are using in the library, which are different when using a separate, custom instance of the OpenCVFrameGrabber class?

Not familiar with SNAPSHOT artifacts. How can I test this issue against them?

@saudet
Copy link
Member

saudet commented Sep 17, 2017 via email

@saudet
Copy link
Member

saudet commented Jan 18, 2018

I've just released JavaCV 1.4. Could you try again with that version and let me know if that still happens? Thanks!

@saudet
Copy link
Member

saudet commented May 24, 2018

Given the lack of feedback, I'm assuming this has been fixed, but please let me know if this isn't the case.

@saudet saudet closed this as completed May 24, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants