[graalvm-users] Creating maven artifacts for native libs

Samuel Audet samuel.audet at gmail.com
Mon Nov 25 22:12:11 PST 2019


+Johan Vos

JavaCV doesn't have a video player per se. It's meant more for image 
analysis and such than anything else. JavaFX is the one with a proper 
video player: https://urldefense.proofpoint.com/v2/url?u=https-3A__openjfx.io_&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=CUkXBxBNT_D5N6HMJ5T9Z6rmvNKYsqupcbk72K0lcoQ&m=yRG8V4fiCasj5kylHRa6GtNPDSmCcXPmaToTQMqf1tQ&s=WNmOREu8Be0P21yYnmASAviyQ77RH1xrFeCiWlGMK9A&e= 

Johan, does it support playback of HEVC media?

Samuel

On 11/26/19 2:43 PM, Ramsey Gurley wrote:
> I think you may have saved me a lot of work :) I'll also check out 
> javacv-platform, since I see you have a swing component to play video in 
> that as well.
> 
> Thank you!
> 
> Ramsey
> 
> On 11/26/19 1:25 PM, Samuel Audet wrote:
>> Hi,
>>
>> In theory, Sulong can compile x265 to fully portable bytecode, and 
>> these files can be packaged into Maven artifacts like any other Java 
>> classes, but the performance that we would get from that may not be 
>> satisfactory. It would probably be around 10x slower than native 
>> binaries since Java bytecode isn't able to accommodate for native 
>> assembly instructions that are used heavily in encoders such as x265. 
>> Also, we may need dependencies on GraalVM, Truffle, and Sulong, so we 
>> wouldn't get a small independent package that could run on the JDK, 
>> but I'm not entirely sure about that. Those projects are still pretty 
>> experimental, so that's probably why I'm not finding a friendly way to 
>> try it out. :)
>>
>> Because of these kinds of limitations, what everyone does, including 
>> very official projects from OpenJDK like JavaFX, is simply to package 
>> native libraries in JAR files and access them with JNI. It works fine 
>> for multiple platforms as well. For example, I'm making packages for 
>> FFmpeg (which include x265) available here:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_bytedeco_javacpp-2Dpresets_tree_master_ffmpeg&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=CUkXBxBNT_D5N6HMJ5T9Z6rmvNKYsqupcbk72K0lcoQ&m=yRG8V4fiCasj5kylHRa6GtNPDSmCcXPmaToTQMqf1tQ&s=reRN9L-_B6iKWP7QIIeZOlY_3KohdhSWO_gQbJnlvBU&e= 
>>
>> There are binaries for Android (ARM, ARM64, x86, x86_64), Linux (ARM, 
>> ARM64, POWER, x86, x86_64), Mac (x86_64), and Windows (x86 and 
>> x86_64), all accessible from a single Maven artifact named 
>> "ffmpeg-platform", but we can create builds easily for more platforms. 
>> To get smaller JAR files, we can also limit the scope of the builds to 
>> small libraries such as only x265 itself.
>>
>> Samuel
>>
>> On 11/25/19 4:47 PM, Ramsey Gurley wrote:
>>> Hi all,
>>>
>>> I'd like to compile a native lib with graal to be distributed as a maven
>>> artifact. I have a few questions.
>>>
>>> Are native libraries platform specific if compiled with graalvm's llvm
>>> tools? Let's say I want to compile x265. Do I need one artifact per
>>> arch? Per os?
>>>
>>> Once created, can the graal compiler used by OpenJDK make use of them?
>>> Or is a graalvm with llvm tools installed a requirement?
>>>
>>> Basically, I want to fill a gap in Java, which is video codecs and a
>>> swing component to use them. I'm hoping graalvm is a good way to do 
>>> this.
>>>
>>> Thank you,
>>>
>>> Ramsey
>>>
>>>




More information about the GraalVM-Users mailing list