64bit support?

[moster67]

Hello and many thanks for your ffmpeg library for Android.

After reading about the new 64bit requirement for Android of native libraries, I noted that your library is not stored in Libs but in Assets. Instructions from Google says to verify for the presence of 64bit by looking at the Directory-names. If I unzip, it only contains Arm and x86 directories and does not give an indication if 64 libs is included.

See this: https://developer.android.com/distribute/best-practices/develop/64-bit

However, your readme seems to indicate support for 64bit when it says armv8 (and x86_64).

Can you confirm that your library is OK with Google's new requirements?

Thanks.

[yagilofir]

+1 for this question. That's a very interesting topic these days.

[jitarun]

Please confirm that this library supports 64 bit?

[Brianvdb]

There are currently no 64 bit libraries added. Will update back on this.

[yarovoiag-cr]

Any changes ?

[nikunjparadva]

Google play console must require 64bit support Please do asap to support this Library. currently 32bit is available , 64 bit folders not found

https://developer.android.com/distribute/best-practices/develop/64-bit#does_your_app_include_64-bit_libraries

Thanks

[kohiyadav]

Please suggest how to generate ffmpeg binaries for 64-bit. I followed https://github.com/WritingMinds/ffmpeg-android link to generate all architecture binaries but the last command in readme file ./android_build.sh fails with following error:

HOST_OS=linux HOST_EXE= HOST_ARCH=x86_64 HOST_TAG=linux-x86_64 HOST_NUM_CPUS=4 BUILD_NUM_CPUS=8 Auto-config: --arch=arm ERROR: Failed to create toolchain. ~/ffmpeg-android/x264 ~/ffmpeg-android Makefile:3: config.mak: No such file or directory ./configure platform: X86_64 byte order: little-endian system: LINUX cli: yes libx264: internal shared: no static: no asm: yes interlaced: yes avs: avxsynth lavf: yes ffms: no mp4: no gpl: yes thread: posix opencl: yes filters: resize crop select_every debug: no gprof: no strip: no PIC: no bit depth: 8 chroma format: all

You can run 'make' or 'make fprofiled' now. rm -f common/mc.o common/predict.o common/pixel.o common/macroblock.o common/frame.o common/dct.o common/cpu.o common/cabac.o common/common.o common/osdep.o common/rectangle.o common/set.o common/quant.o common/deblock.o common/vlc.o common/mvpred.o common/bitstream.o encoder/analyse.o encoder/me.o encoder/ratecontrol.o encoder/set.o encoder/macroblock.o encoder/cabac.o encoder/cavlc.o encoder/encoder.o encoder/lookahead.o common/threadpool.o common/x86/mc-c.o common/x86/predict-c.o common/opencl.o encoder/slicetype-cl.o common/x86/const-a.o common/x86/cabac-a.o common/x86/dct-a.o common/x86/deblock-a.o common/x86/mc-a.o common/x86/mc-a2.o common/x86/pixel-a.o common/x86/predict-a.o common/x86/quant-a.o common/x86/cpu-a.o common/x86/dct-64.o common/x86/bitstream-a.o common/x86/sad-a.o common/x86/trellis-64.o x264.o input/input.o input/timecode.o input/raw.o input/y4m.o output/raw.o output/matroska.o output/matroska_ebml.o output/flv.o output/flv_bytestream.o filters/filters.o filters/video/video.o filters/video/source.o filters/video/internal.o filters/video/resize.o filters/video/cache.o filters/video/fix_vfr_pts.o filters/video/select_every.o filters/video/crop.o filters/video/depth.o input/avs.o input/thread.o input/lavf.o .a .lib .exp .pdb x264 x264.exe .depend TAGS rm -f checkasm checkasm.exe tools/checkasm.o tools/checkasm-a.o common/oclobj.h x264_lookahead.clbin rm -f example example.exe example.o rm -f common/mc.gcda common/predict.gcda common/pixel.gcda common/macroblock.gcda common/frame.gcda common/dct.gcda common/cpu.gcda common/cabac.gcda common/common.gcda common/osdep.gcda common/rectangle.gcda common/set.gcda common/quant.gcda common/deblock.gcda common/vlc.gcda common/mvpred.gcda common/bitstream.gcda encoder/analyse.gcda encoder/me.gcda encoder/ratecontrol.gcda encoder/set.gcda encoder/macroblock.gcda encoder/cabac.gcda encoder/cavlc.gcda encoder/encoder.gcda encoder/lookahead.gcda common/threadpool.gcda common/x86/mc-c.gcda common/x86/predict-c.gcda common/opencl.gcda encoder/slicetype-cl.gcda x264.gcda input/input.gcda input/timecode.gcda input/raw.gcda input/y4m.gcda output/raw.gcda output/matroska.gcda output/matroska_ebml.gcda output/flv.gcda output/flv_bytestream.gcda filters/filters.gcda filters/video/video.gcda filters/video/source.gcda filters/video/internal.gcda filters/video/resize.gcda filters/video/cache.gcda filters/video/fix_vfr_pts.gcda filters/video/select_every.gcda filters/video/crop.gcda filters/video/depth.gcda input/avs.gcda input/thread.gcda input/lavf.gcda common/mc.gcno common/predict.gcno common/pixel.gcno common/macroblock.gcno common/frame.gcno common/dct.gcno common/cpu.gcno common/cabac.gcno common/common.gcno common/osdep.gcno common/rectangle.gcno common/set.gcno common/quant.gcno common/deblock.gcno common/vlc.gcno common/mvpred.gcno common/bitstream.gcno encoder/analyse.gcno encoder/me.gcno encoder/ratecontrol.gcno encoder/set.gcno encoder/macroblock.gcno encoder/cabac.gcno encoder/cavlc.gcno encoder/encoder.gcno encoder/lookahead.gcno common/threadpool.gcno common/x86/mc-c.gcno common/x86/predict-c.gcno common/opencl.gcno encoder/slicetype-cl.gcno x264.gcno input/input.gcno input/timecode.gcno input/raw.gcno input/y4m.gcno output/raw.gcno output/matroska.gcno output/matroska_ebml.gcno output/flv.gcno output/flv_bytestream.gcno filters/filters.gcno filters/video/video.gcno filters/video/source.gcno filters/video/internal.gcno filters/video/resize.gcno filters/video/cache.gcno filters/video/fix_vfr_pts.gcno filters/video/select_every.gcno filters/video/crop.gcno filters/video/depth.gcno input/avs.gcno input/thread.gcno input/lavf.gcno .dyn pgopti.dpi pgopti.dpi.lock .pgd *.pgc -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-strict-overflow -fstack-protector-all No working C compiler found.

I have searched alot but did not get anything.

Please help Thanks

[8285497507]

By August 1, 2019, all apps that use native code must provide a 64-bit version in addition to the 32-bit version in order to publish an update. This past January, we reiterated that this is required in order to make way for innovation and in anticipation of future Android devices that only support 64-bit code.As the deadline approaches, we wanted to remind you that at least one of your apps* uses native code but does not currently offer a 64-bit variant:	By August 1, 2019, all apps that use native code must provide a 64-bit version in addition to the 32-bit version in order to publish an update. This past January, we reiterated that this is required in order to make way for innovation and in anticipation of future Android devices that only support 64-bit code.As the deadline approaches, we wanted to remind you that at least one of your apps* uses native code but does not currently offer a 64-bit variant:	By August 1, 2019, all apps that use native code must provide a 64-bit version in addition to the 32-bit version in order to publish an update. This past January, we reiterated that this is required in order to make way for innovation and in anticipation of future Android devices that only support 64-bit code.	As the deadline approaches, we wanted to remind you that at least one of your apps* uses native code but does not currently offer a 64-bit variant:
By August 1, 2019, all apps that use native code must provide a 64-bit version in addition to the 32-bit version in order to publish an update. This past January, we reiterated that this is required in order to make way for innovation and in anticipation of future Android devices that only support 64-bit code.As the deadline approaches, we wanted to remind you that at least one of your apps* uses native code but does not currently offer a 64-bit variant:	By August 1, 2019, all apps that use native code must provide a 64-bit version in addition to the 32-bit version in order to publish an update. This past January, we reiterated that this is required in order to make way for innovation and in anticipation of future Android devices that only support 64-bit code.	As the deadline approaches, we wanted to remind you that at least one of your apps* uses native code but does not currently offer a 64-bit variant:

By August 1, 2019, all apps that use native code must provide a 64-bit version in addition to the 32-bit version in order to publish an update. This past January, we reiterated that this is required in order to make way for innovation and in anticipation of future Android devices that only support 64-bit code. As the deadline approaches, we wanted to remind you that at least one of your apps* uses native code but does not currently offer a 64-bit variant:

#How to create library that support 64 bit ..........

[ghost]

If you share the compiler script? Is the best option to reduce binary size or add https support

[niallwatchorn]

Any updates on this? Is there a 64-bit library available yet? Time is edging closer to the cutoff point, and I assume many apps on Android use FFMPEG for video editing. Be useful to get it updated to 64 bit asap.

Also, any plans to implement hardware acceleration? Currently runs so slowly on the Pixel 3 doing basic operations.

[yadavkohi]

Hello guys,

I am working on 64-bit ffmpeg binaries. Once completed I will update you on it.

[nikunjparadva]

@yadavkohi have you completed this 64bit update?, I am really waiting for that

[yadavkohi]

guys still working on it.

[sushinpv]

Hi @yadavkohi ,

We are literally waiting for your update

[thucnd55]

Any update ? Why i can not find any question in google search with this problem. It's so Critical @@

[formatBCE]

I can't even imagine, how many apps are using this library, and how many devs are waiting for update...

[sysquare]

@yadavkohi , any rough idea by when everyone can get it ? 32 bit support will shut down in 4 weeks

[yadavkohi]

I will try to finish it by mid july

[8285497507]

Guys , i got Solution for this problems. now wait for 2 days to confirmation

[formatBCE]

Hey guys. Could it be, that, since library is using ffmpeg binary by itself (copy -> run), it should work as is? There's no any pre-compilled .so files, referring to certain architecture. It's just binary executable file, which is launched by app itself, and has no influence in code (and it is in assets folder, btw). So it could be possible, that Google will know nothing about this binary during app publishing.

[8285497507]

android { compileSdkVersion 29 defaultConfig { applicationId "com.xyz.videoEditor" minSdkVersion 16 targetSdkVersion 29 versionCode 2 ndk.abiFilters 'arm64-v8a','x86_64' //Ads this line versionName "1.2"

    multiDexEnabled true
    testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
}

[formatBCE]

In which world should it resolve current issue, and how? It just filters 64-bit architectures, but we don't want that!

[thucnd55]

In short time, i'm using https://github.com/tanersener/mobile-ffmpeg for hot fix . It'seem be resolve 64-bit issue

[sysquare]

@yadavkohi any update ? Also, may I know who are the persons who has ownership of this ticket. Can we know when and from whom we can expect this fix so that stop asking everyday. Its on SEV-1 now in our project

Does anyone has any idea that what worst can happen if we were not able to update before August1 and is there any workaround or temporary solution ?

[sysquare]

Hey ALL, I just uploaded a build on play store and its not showing me any warning for 64 bit, is there anything which got changed ?

[formatBCE]

As i suggested, most probably we'll be all good with this library. Binary native file is used from assets folder, and Google takes eye on lib folder.

[sysquare]

May be you are true but my concern is that until my last upload on play store(which was approx 3 weeks before) google was giving me 64-bit warning but now its not. I have not changed anything.

[yadavkohi]

Hello guys,

I have created the 64-bit binaries. Please follow the below git repository.

https://github.com/yadavkohi/FFmpeg-64Bit

[sysquare]

Thanks @yadavkohi Do we have to just add binaries provided in above link under "src/main/assets/" ?? Thats it or something else needs to be done ?

[yadavkohi]

yes just add the binaries under "src/main/assets" and try with your ffmpeg commands.

[shiv71]

@yadavkohi
Thanks for the 64 Bit binary updates. I have integrated it into my project using like below

dependencies { implementation 'nl.bravobit:android-ffmpeg:1.1.7' }

Will I get 64 bit binaries automatically ? or Do I have to do something ?

Or do I need to add the library manually into assets folder. I would prefer the dependencies way.

[formatBCE]

This binaries should be included into library. Moreover, there should be a code with correct assets folder path according to device architecture. So some changes in library itself should be done as well. I have forked this lib, and will prepare changes today. But the bad thing is, that with current implementation, all native binaries will be included into apk file, adding extra 9 MB per file. At this point it's 2 files, but after adding 2 more for x64 arch, lib size will be around 40 MB. Worth it?

[yadavkohi]

Just add the library manually to your assets folder

[sysquare]

@yadavkohi : For adding manually, I have to add the source. I am also using this library using gradle dependency

Is there any way to get it through dependency ? i am using below version right now

dependencies { implementation 'nl.bravobit:android-ffmpeg:1.1.7' }

[yadavkohi]

I don't think it is correct to modify someone else repository. So you can create a pull request with these addition.

[formatBCE]

No, you can't just add this to assets folder. Case is, that in logic, there's if-else statement, which decides exact assets subfolder for ffmpeg binary. And there is same branch for x86 and x86_64 architectures. So without code changing this files will be just useless. Take a look at my fork: https://github.com/formatBCE/FFmpeg-Android Last commit there added 64-bit executables, correct code for using them. Also i finally removed FFprobe - it is useless for me, and still there's no 64-bit binaries for it. P.S. I left 32-bit executables untouched, just added two 64-bit variants - arm64-v8a and x86_64

[formatBCE]

@yadavkohi thank you, seems working correctly.

[stanchovy]

Forgive my ignorance @formatBCE -- how do we link our gradle builds to pick up the forked library in https://github.com/formatBCE/FFmpeg-Android

The following will just pick up the unfixed version, right? What should we change it to?

dependencies { implementation 'nl.bravobit:android-ffmpeg:1.1.7' }

Thanks.

[formatBCE]

Sorry, there's no simple way - i can't publish that repo to maven central, and i doubt that bravobit will merge pull-request from my fork. I use it as aar lib for our project. Just clone repo into separate Android Studio project, and build it - you'll find aar library in build/outputs folder of main module.

[thucnd55]

@formatBCE So, how can i do to moving 64-bit lib if i'm using

dependencies {
    implementation 'nl.bravobit:android-ffmpeg:1.1.7'
}

[thucnd55]

Sorry, there's no simple way - i can't publish that repo to maven central, and i doubt that bravobit will merge pull-request from my fork. I use it as aar lib for our project. Just clone repo into separate Android Studio project, and build it - you'll find aar library in build/outputs folder of main module.

Oh, i got it, But it's quite manually

[formatBCE]

Well, it is as it is. Since i'm not affiliated with Bravobit, i can't do anything about it...

[yadavkohi]

Hello guys,

who are using this project as sub-module just made some java file changes to adopt the 64-bit binary support. I have added those java file in my repository.

[alonsd]

@yadavkohi how do I implement the files on my project already using the old repository?

[yadavkohi]

just replace the mention .java files and library in assets folder

[alonsd]

alright, I will try so. but if I am using the libARM_ARCH.so library your solution won't help me, am I right? @yadavkohi and if it is right, do you have any other suggestions that might help me with it?

[yadavkohi]

I have shared the static binaries which is different from .so files.

[alonsd]

I still don't understand. Does that mean that it won't help me with the libARM_ARCH.so ? Also, I am trying anyway to implement it to try - I don't have any of the .java files that you putted in the repo, so where should I put it? just in the main folder?

[yadavkohi]

I have created a repository for .SO files. Please refer the below repo: https://github.com/yadavkohi/FFmpegSO

[alonsd]

Thank you so much. That is really helpfull. Can you please update the readme for instructions on what to do?

[alonsd]

@yadavkohi I am getting the following error when trying to compile my code after integrating your library (manually) -

Plugin with id 'com.jfrog.bintray' not found. Open File

any idea why it is happening?