Use locking callback from ffmpeg using a Java locking mechanism.

[mifritscher]

Signed-off-by: Michael Fritscher [email protected]

[mastah84]

While this change allows me to make few pretty code reorganizations, it doesnt resolve problem from referenced issue.

PS. You can make some good use of CountDownLatch in Your testfile.

[saudet]

@mifritscher Looks good! But I don't think we need to allocate any native memory manually with Pointer. Although what we need to return is a Pointer object, we can just return any arbitrary integer with Pointer.address, in occurrence lockCounter looks like a good candidate, and use it to query the HashMap.

Also, would you have any objections in naming the class FFmpegLockCallback, for consistency with FFmpegLogCallback?

[mifritscher]

@allocating: I don't know if I understand you correctly. If I understood the documentation correctly, I can only store a pointer to my "lockdata" to it, no real data (e.g. my Counter). It could work if I sneeze in an integer in it, but I wanted to be on the safe side (e.g. if ffmpeg do "funny things" with the pointer)

Regarding rename: Choose whatever name you like ;-)

[saudet]

It can't do anything to memory it doesn't allocate, so yes we can put whatever we want as address.

[mifritscher]

So it is ok to break the "should" in

the "mutex" argument to the function points to a (void *) where the lockmgr should store/get a pointer to a user allocated mutex.

?
Another thing is that a pointer is 32 bit on some architectures, 64 bit on others. If you want I can try to save a 32 bit counter as "pointer".

[saudet]

A pointer in C/C++ is just an integer, and that's all we need. The memory allocated is on the Java heap, so we don't need to allocate native memory. The pointer size might be just 32 bits, yes, but that's fine.

[mifritscher]

O, I did made both changes and committed them. I don't know whether travis built it - https://travis-ci.org/bytedeco/javacv/builds/270335084?utm_source=github_status&utm_medium=notification says "not started", while https://travis-ci.org/bytedeco/javacv/requests says "Build created successfully"

[saudet]

The build seems to be backlogged, let's wait a bit. Looks good though, thanks :)

BTW, new IntPointer(mutex).get()/put() is probably more efficient. Creating a Buffer is pretty expensive...

[mifritscher]

Don't know what way is more expensive - but you can choose now :-)
Hmm, https://www.traviscistatus.com/ doesn't mention a major backlog... (We don't build on MacOS X here, do we?^^)

[saudet]

One last thing, please remove the tabs, but looks good otherwise! Thanks

[mifritscher]

Sorry, my eclipse uses the standard Java recommendations. I've fixed the indentation in the newest commit.