ffmpeg-android-java
ffmpeg-android-java copied to clipboard
cropsly
ARMv7-Neon entry is missing under CPUArch EnumType
In the update (0.3.2) ARMv7-Neon entry is missing under CPUArch EnumType
What would be the value in case we want to add Neon ffmpeg as well
Neon is still supported by normal ARMv7 binary. In case you need to add neon binaries you need to follow the approach used by 0.2.x library.
But I'd say that pointless as the instruction set of ARMv7 is supported by ARMv7-Neon and including neon binaries results in bigger apk size.
Ok, does that mean in 0.3.2 there is no "non-neon" version? is ARMv7 is the neon version, should it not be named ARMv7-Neon to avoid confusion?
in https://github.com/writingminds/ffmpeg-android latest files the FFMpeg exists for ARMv7, ARMv7-Neon. So which file is included in 0.3.2 of FFMpeg-Android-java?
0.3.2 has no neon binary, it just have ARMv7 binary.
Just for the clarification 0.3.2 has two binaries - ARMv7 which supports armv7, armv7-neon, armv8 x86 which supports x86, x86_64
So to reiterate the FFmpeg file in ARMv7 folder would support armv7, armv7-neon, armv8-64 & the file in x86 will support both X86 and X64
So does this mean there is no support for ARM
In the libs folder that houses the libARM_ARCH.so there are folders armeabi, armeabi-v7a and x86, but for armv8 is missing.
If you could help clear the confusion, I would be grateful.
@gouravd If i'm right ,there is no need for a seperate Arm8 folder , it is already supported by armv7 folder , you can check the updated binaries in assest folder [here]
basically,there are only two folders -armeabi-v7a (which supports armv8-64 as well, forget the v7 name) and x86 (which support x86 and x86_64)
Now moving to libs folder - there are three folders- armeabi-v7a ,armeabi ,x86 In which ARM8 is supported by armebi folders (just forget the name again "v7a") these folders are not updated since two year ,so the name has not been changed.
@JayParikh20 The naming is there but for a reason. Here are few pointers -
- armeabi-v7a has binary which is compiled for armeabi-v7a. Now as instruction set of armeabi-v7a is supported by armeabi-v7a-neon, armv8/arm64, so in order to have reduced size apk its best to use the same binary for the platforms. Thats the reason we have only one binary compiled for armeabi-v7a which supports all major arm variants.
- x86 has binary which is compiled for x86. Now as instruction set of x86 is supported by x86-64 thats why we don't have a separate directory for x86-64 binary. As we are supporting x86-64 with x86 binary.
I hope I make it clear to you guys.
@hiteshsondhi88
Now as instruction set of armeabi-v7a is supported by armeabi-v7a-neon, armv8/arm64, so in order to have reduced size apk its best to use the same binary for the platforms.
Now as instruction set of x86 is supported by x86-64 thats why we don't have a separate directory for x86-64 binary.
But what about performance? x86-64 binary on x86-64 device (x86-64 CPU + x86-64 OS) is faster than x86-32 binary on x86-64 device. Right? Is FFMPEG contains any optimization for 64 bit and new instruction sets?
BTW, what about MIPS and MIPS64? What about ARMv6-FPU and ARMv6-NoFPU?
What about releasing multiple APKs for different architectures (https://developer.android.com/google/play/publishing/multiple-apks.html)? See #66.
@JayParikh20 The naming is there but for a reason. Here are few pointers -
- armeabi-v7a has binary which is compiled for armeabi-v7a. Now as instruction set of armeabi-v7a is supported by armeabi-v7a-neon, armv8/arm64, so in order to have reduced size apk its best to use the same binary for the platforms. Thats the reason we have only one binary compiled for armeabi-v7a which supports all major arm variants.
- x86 has binary which is compiled for x86. Now as instruction set of x86 is supported by x86-64 thats why we don't have a separate directory for x86-64 binary. As we are supporting x86-64 with x86 binary.
I hope I make it clear to you guys.
Hi @FluorescentHallucinogen . I'm updating my app to support 64-bit in time for the August deadline set by Google, and I was researching FFMPEG's support as the Google instructions on supporting 64-bit listed here says that if you find any .so files then you need to update your app to support 64-bit. I found this thread after Googling the filename 'libARM_ARCH.so' and your comment leads me to believe that further action isn't required, despite Google's instructions stating otherwise, is this correct? I hope so, that would be amazing, saves me the headache if so! 🤕
