WAI
Status Update
No update yet.
Comments
jz...@google.com
Thanks for the report. It looks like avx2 is being forcibly enabled or miss detected at runtime. If you create a toolchain with make_standalone_toolchain.py and use the library built with the default configure [1] does the issue still occur? You can also try --disable-avx2 to clear this particular issue.
[1] CROSS=x86_64-linux-android- ../configure --target=x86_64-android-gcc --disable-examples --disable-unit-tests --disable-tools
[1] CROSS=x86_64-linux-android- ../configure --target=x86_64-android-gcc --disable-examples --disable-unit-tests --disable-tools
cm...@gmail.com
I included the option --disable-avx2 for all ABIS built; it fixes the reported problem on AVD pixel-2_API-28 running on x86_64 platform (i7)
There is a problem when build vpx with standalone toolchains i.e. remove option --sdk-path=${NDK} in ./build-libvpx4android.sh
# Standalone toolchains built has problem with ABIS="armeabi-v7a"
# /tmp/vpx-conf-31901-2664.o(.ARM.exidx.text.main+0x0): error: undefined reference to '__aeabi_unwind_cpp_pr0'
Please refer to the latest build scripts for more information:
https://github.com/cmeng-git/vpx-android
There is a problem when build vpx with standalone toolchains i.e. remove option --sdk-path=${NDK} in ./build-libvpx4android.sh
# Standalone toolchains built has problem with ABIS="armeabi-v7a"
# /tmp/vpx-conf-31901-2664.o(.ARM.exidx.text.main+0x0): error: undefined reference to '__aeabi_unwind_cpp_pr0'
Please refer to the latest build scripts for more information:
jz...@google.com
From your build-libvpx4android.sh script.
> ./configure \
> --sdk-path=${NDK} \
> --extra-cflags="-isystem ${NDK_SYSROOT}/usr/include/${NDK_ABIARCH} -isystem ${NDK_SYSROOT}/usr/include" \
> --libc=${NDK_SYSROOT} \
> --prefix=${PREFIX} \
> --target=${TARGET} \
> --as=yasm \
> --enable-pic \
> --disable-runtime-cpu-detect \
This is the problem with the emulator. With this disabled the library assumes
it can execute all assembly built in to the library. The fix is to drop this
for at least x86 builds or use --disable-avx2.
> --disable-docs \
> --enable-static \
> --enable-libyuv \
> --disable-examples \
> --disable-tools \
> --disable-debug \
> --disable-unit-tests \
> --disable-avx2 \
> --enable-realtime-only \
> --enable-vp8 \
> --enable-vp9 \
> --disable-webm-io || exit 1
> ./configure \
> --sdk-path=${NDK} \
> --extra-cflags="-isystem ${NDK_SYSROOT}/usr/include/${NDK_ABIARCH} -isystem ${NDK_SYSROOT}/usr/include" \
> --libc=${NDK_SYSROOT} \
> --prefix=${PREFIX} \
> --target=${TARGET} \
> --as=yasm \
> --enable-pic \
> --disable-runtime-cpu-detect \
This is the problem with the emulator. With this disabled the library assumes
it can execute all assembly built in to the library. The fix is to drop this
for at least x86 builds or use --disable-avx2.
> --disable-docs \
> --enable-static \
> --enable-libyuv \
> --disable-examples \
> --disable-tools \
> --disable-debug \
> --disable-unit-tests \
> --disable-avx2 \
> --enable-realtime-only \
> --enable-vp8 \
> --enable-vp9 \
> --disable-webm-io || exit 1
jz...@google.com
[Empty comment from Monorail migration]
cm...@gmail.com
Thanks for your clarifications
I am now using "--enable-runtime-cpu-detect" to build vpx for ABIS=x86/x86_64 for aTalk; has verified working.
I have update the scripts (v1.1.3) and the standalone toolchains build for vpx is now working (ndk-r15c/ndk-r17c with clang) except for armeabi-v7a i.e.:
## Standalone toolchains work for ABIS=("arm64-v8a" "x86" "x86_64")
ABIS "armeabi-v7a" has errors i.e.
clang50: error: unsupported option '--defsym'
clang50: error: no such file or directory: 'ARCHITECTURE=7'
I am now using "--enable-runtime-cpu-detect" to build vpx for ABIS=x86/x86_64 for aTalk; has verified working.
I have update the scripts (v1.1.3) and the standalone toolchains build for vpx is now working (ndk-r15c/ndk-r17c with clang) except for armeabi-v7a i.e.:
## Standalone toolchains work for ABIS=("arm64-v8a" "x86" "x86_64")
ABIS "armeabi-v7a" has errors i.e.
clang50: error: unsupported option '--defsym'
clang50: error: no such file or directory: 'ARCHITECTURE=7'
jz...@google.com
> clang50: error: unsupported option '--defsym'
> clang50: error: no such file or directory: 'ARCHITECTURE=7'
Despite the 'check' in the function name, those flags are added unconditionally
at the moment [1] and are meant for use with the as tool. ${CROSS_PREFIX}as
should work in your script.
[1]https://chromium.googlesource.com/webm/libvpx/+/refs/heads/master/build/make/configure.sh#1020
> clang50: error: no such file or directory: 'ARCHITECTURE=7'
Despite the 'check' in the function name, those flags are added unconditionally
at the moment [1] and are meant for use with the as tool. ${CROSS_PREFIX}as
should work in your script.
[1]
cm...@gmail.com
For build with standalone toolchanis:
when I issue the command ./build-libvpx4android.sh armeabi-v7a; everything seems to compile properly until near the end i.e.
[CC] vp9/decoder/vp9_dsubexp.c.o
[CC] vpx_config.c.o
[CREATE] vpx_config.asm
[CREATE] vpx.pc
[AS] vpx_dsp/arm/intrapred_neon_asm.asm.S.o
[AS] vpx_dsp/arm/vpx_convolve_copy_neon_asm.asm.S.o
clang50: error: unsupported option '--defsym'
clang50: error: no such file or directory: 'ARCHITECTURE=7'
clang50: error: unsupported option '--defsym'
clang50: error: no such file or directory: 'ARCHITECTURE=7'
make[1]: *** [vpx_dsp/arm/vpx_convolve_copy_neon_asm.asm.S.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: *** [vpx_dsp/arm/intrapred_neon_asm.asm.S.o] Error 1
make: *** [.DEFAULT] Error 2
~/workspace/ndk/vpx-android
** BUILD COMPLETED: libvpx for armeabi-v7a **
As for other the other ABIS, they build without any error.
when I issue the command ./build-libvpx4android.sh armeabi-v7a; everything seems to compile properly until near the end i.e.
[CC] vp9/decoder/vp9_dsubexp.c.o
[CC] vpx_config.c.o
[CREATE] vpx_config.asm
[CREATE] vpx.pc
[AS] vpx_dsp/arm/intrapred_neon_asm.asm.S.o
[AS] vpx_dsp/arm/vpx_convolve_copy_neon_asm.asm.S.o
clang50: error: unsupported option '--defsym'
clang50: error: no such file or directory: 'ARCHITECTURE=7'
clang50: error: unsupported option '--defsym'
clang50: error: no such file or directory: 'ARCHITECTURE=7'
make[1]: *** [vpx_dsp/arm/vpx_convolve_copy_neon_asm.asm.S.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: *** [vpx_dsp/arm/intrapred_neon_asm.asm.S.o] Error 1
make: *** [.DEFAULT] Error 2
~/workspace/ndk/vpx-android
** BUILD COMPLETED: libvpx for armeabi-v7a **
As for other the other ABIS, they build without any error.
jo...@google.com
ARCHITECTURE was used a very long time ago to distinguish between armv5/6/7 optimizations. It hasn't been used in quite some time so we can remove it.
bu...@chops-service-accounts.iam.gserviceaccount.com
The following revision refers to this bug:
https://chromium.googlesource.com/webm/libvpx/+/4bc723fabc976ba110c841e28f3db6049e89a25e
commit 4bc723fabc976ba110c841e28f3db6049e89a25e
Author: Johann <johannkoenig@google.com>
Date: Tue Apr 23 16:48:35 2019
remove ARCHITECTURE definition
In the distant past this was used to distinguish between
armv5/6/7 targets when building the assembly files. The
project has not supported armv5/6 for a long time.
BUG=webm:1623
Change-Id: Ibec70e6624b651df0fa6f882ab6f201dc73e92e2
[modify]https://crrev.com/4bc723fabc976ba110c841e28f3db6049e89a25e/build/make/configure.sh
[modify]https://crrev.com/4bc723fabc976ba110c841e28f3db6049e89a25e/build/make/ads2gas_apple.pl
commit 4bc723fabc976ba110c841e28f3db6049e89a25e
Author: Johann <johannkoenig@google.com>
Date: Tue Apr 23 16:48:35 2019
remove ARCHITECTURE definition
In the distant past this was used to distinguish between
armv5/6/7 targets when building the assembly files. The
project has not supported armv5/6 for a long time.
BUG=webm:1623
Change-Id: Ibec70e6624b651df0fa6f882ab6f201dc73e92e2
[modify]
[modify]
cm...@gmail.com
Thanks for the update.
Using your latest master repository, previous problems have been resolved. However new error appear (amreabi-v7a) as below for built using either
ndk-r15c or ndk-r17c.
Please note that to build arm64-v8a successfully for standard NDK, you must also apply the patches as described below.
Otherwise configure.sh will use armeabi-v7a configuration to build arm64-v8a:
https://bugs.chromium.org/p/webm/issues/detail?id=1622&q=&colspec=ID%20Pri%20mstone%20ReleaseBlock%20Type%20Component%20Status%20Owner%20Summary
Not sure if the problem below is due to android ndk for clang. I did not test with gcc.
========== build error ==========
[CC] vp9/decoder/vp9_job_queue.c.o
[CC] vpx_config.c.o
[CREATE] vpx_config.asm
[CREATE] vpx.pc
[AS] vpx_dsp/arm/intrapred_neon_asm.asm.S.o
[AS] vpx_dsp/arm/vpx_convolve_copy_neon_asm.asm.S.o
/home/cmeng/workspace/ndk/vpx-android/android-toolchain/bin/../sysroot/usr/lib/../lib/crtbegin_dynamic.o:crtbegin.c:function _start: error: undefined reference to 'main'
clang50: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [vpx_dsp/arm/intrapred_neon_asm.asm.S.o] Error 1
make[1]: *** Waiting for unfinished jobs....
/home/cmeng/workspace/ndk/vpx-android/android-toolchain/bin/../sysroot/usr/lib/../lib/crtbegin_dynamic.o:crtbegin.c:function _start: error: undefined reference to 'main'
clang50: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [vpx_dsp/arm/vpx_convolve_copy_neon_asm.asm.S.o] Error 1
make: *** [.DEFAULT] Error 2
~/workspace/ndk/vpx-android
** BUILD COMPLETED: libvpx for armeabi-v7a **
Using your latest master repository, previous problems have been resolved. However new error appear (amreabi-v7a) as below for built using either
ndk-r15c or ndk-r17c.
Please note that to build arm64-v8a successfully for standard NDK, you must also apply the patches as described below.
Otherwise configure.sh will use armeabi-v7a configuration to build arm64-v8a:
Not sure if the problem below is due to android ndk for clang. I did not test with gcc.
========== build error ==========
[CC] vp9/decoder/vp9_job_queue.c.o
[CC] vpx_config.c.o
[CREATE] vpx_config.asm
[CREATE] vpx.pc
[AS] vpx_dsp/arm/intrapred_neon_asm.asm.S.o
[AS] vpx_dsp/arm/vpx_convolve_copy_neon_asm.asm.S.o
/home/cmeng/workspace/ndk/vpx-android/android-toolchain/bin/../sysroot/usr/lib/../lib/crtbegin_dynamic.o:crtbegin.c:function _start: error: undefined reference to 'main'
clang50: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [vpx_dsp/arm/intrapred_neon_asm.asm.S.o] Error 1
make[1]: *** Waiting for unfinished jobs....
/home/cmeng/workspace/ndk/vpx-android/android-toolchain/bin/../sysroot/usr/lib/../lib/crtbegin_dynamic.o:crtbegin.c:function _start: error: undefined reference to 'main'
clang50: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [vpx_dsp/arm/vpx_convolve_copy_neon_asm.asm.S.o] Error 1
make: *** [.DEFAULT] Error 2
~/workspace/ndk/vpx-android
** BUILD COMPLETED: libvpx for armeabi-v7a **
jo...@google.com
ndk-build V=1
or
ndk-build VERBOSE=1
might give some indication of what is happening.
For reference you can see a successful armv7 ndk build here:
https://build.webmproject.org/jenkins/view/libvpx%20nightly/job/libvpx__compile_android/947/APP_ABI=armeabi-v7a,APP_OPTIM=release,APP_STL=c++_static,NDK_TOOLCHAIN_VERSION=clang,build_type=ndk,shared=0/console
19:43:20 + ./libvpx/configure --target=armv7-android-gcc --disable-docs --sdk-path=/opt/android-ndk-r18/ --enable-external-build
19:43:20 + ndk-build APP_BUILD_SCRIPT=./libvpx/test/android/Android.mk APP_ABI=armeabi-v7a APP_PLATFORM=android-21 APP_OPTIM=release APP_STL=c++_static NDK_TOOLCHAIN_VERSION=clang ENABLE_SHARED=0
There is also an arm64-v8a configuration which does not require any patches to configure:
https://build.webmproject.org/jenkins/view/libvpx%20nightly/job/libvpx__compile_android/947/APP_ABI=arm64-v8a,APP_OPTIM=release,APP_STL=c++_static,NDK_TOOLCHAIN_VERSION=clang,build_type=ndk,shared=0/console
or
ndk-build VERBOSE=1
might give some indication of what is happening.
For reference you can see a successful armv7 ndk build here:
19:43:20 + ./libvpx/configure --target=armv7-android-gcc --disable-docs --sdk-path=/opt/android-ndk-r18/ --enable-external-build
19:43:20 + ndk-build APP_BUILD_SCRIPT=./libvpx/test/android/Android.mk APP_ABI=armeabi-v7a APP_PLATFORM=android-21 APP_OPTIM=release APP_STL=c++_static NDK_TOOLCHAIN_VERSION=clang ENABLE_SHARED=0
There is also an arm64-v8a configuration which does not require any patches to configure:
jo...@google.com
From the grey dots here:
https://build.webmproject.org/jenkins/view/libvpx%20nightly/job/libvpx__compile_android/
You can see that we have stopped testing standalone builds for arm. They are too much trouble. Please try ndk-build.
You can see that we have stopped testing standalone builds for arm. They are too much trouble. Please try ndk-build.
cm...@gmail.com
> 10:43:20 + ./libvpx/configure --target=armv7-android-gcc --disable-docs --sdk-path=/opt/android-ndk-r18/ --enable-external-build
I may not have fully understood the build log file, not sure if my below observations are correct:
From the log reference, the successful built for armeabi-v7a is actually using the original NDK toolchains when a configure option (see above) i.e. --sdk-path=/opt/android-ndk-r18/ is specified; the successful built teddies with my observation.
The problem that I was referred to in my previous comment happen only when libvxp is built with a "standalone toolchains" generated with make_standalone_toolchain.py and without the configure option --sdk-path=/opt/android-ndk-r18/ being specified.
Note: My observation was that when configure option --sdk-path=/opt/android-ndk-r18/ is specified, the libvpx build script will ignore the standalone toolchanis and use the original ndk toolchanins. However I am also confused why android-ndk-r18 is working because gcc support has be removed in r18c
https://developer.android.com/ndk/downloads/revision_history where it mentioned:
GCC has been removed.
or was it because the below build option is being specified
NDK_TOOLCHAIN_VERSION=clang
================
> There is also an arm64-v8a configuration which does not require any patches to configure:
Do you actually check the config.log to see if it is actually build the arm64-v8a lib?
My previous observation was that, without the patches, thelibs.arm64-android-gcc.mk file generated actually specifies use of
arm-linux-androideabi-gcc instead of aarch64-linux-android-gcc for 64-bit architecture build.
This is actually reflected in the configure.sh scripts, i.e. there is no logic to differentiate between arm and arm64 architeture build.
The patches check for arm and arm64 and generate the script accordingly.
Please refer to the following:
Unable to compile ffmpeg in arm64-v8a #1
https://github.com/cmeng-git/ffmpeg-android/issues/1
I may not have fully understood the build log file, not sure if my below observations are correct:
From the log reference, the successful built for armeabi-v7a is actually using the original NDK toolchains when a configure option (see above) i.e. --sdk-path=/opt/android-ndk-r18/ is specified; the successful built teddies with my observation.
The problem that I was referred to in my previous comment happen only when libvxp is built with a "standalone toolchains" generated with make_standalone_toolchain.py and without the configure option --sdk-path=/opt/android-ndk-r18/ being specified.
Note: My observation was that when configure option --sdk-path=/opt/android-ndk-r18/ is specified, the libvpx build script will ignore the standalone toolchanis and use the original ndk toolchanins. However I am also confused why android-ndk-r18 is working because gcc support has be removed in r18c
GCC has been removed.
or was it because the below build option is being specified
NDK_TOOLCHAIN_VERSION=clang
================
> There is also an arm64-v8a configuration which does not require any patches to configure:
Do you actually check the config.log to see if it is actually build the arm64-v8a lib?
My previous observation was that, without the patches, the
arm-linux-androideabi-gcc instead of aarch64-linux-android-gcc for 64-bit architecture build.
This is actually reflected in the configure.sh scripts, i.e. there is no logic to differentiate between arm and arm64 architeture build.
The patches check for arm and arm64 and generate the script accordingly.
Please refer to the following:
Unable to compile ffmpeg in arm64-v8a #1
cm...@gmail.com
Actually for libvpx build for aTalk, I do not use standalone toolchains as it really has too much problems.
jo...@google.com
I haven't tested it in a while, but they standalone did work at one time with aarch64.
libvpx/build/make/Android.mk:
# For example - to test on arm64 devices with clang:
# $NDK/build/tools/make_standalone_toolchain.py \
# --arch arm64 --install-dir=/tmp/my-android-toolchain
# export PATH=/tmp/my-android-toolchain/bin:$PATH
# CROSS=aarch64-linux-android- CC=clang CXX=clang++ /path/to/libvpx/configure \
# --target=arm64-android-gcc
Note the CROSS/CC settings
AS mentioned though, this has been a difficult path to maintain. I'd prefer to remove it:
https://chromium-review.googlesource.com/c/webm/libvpx/+/1593687
libvpx/build/make/Android.mk:
# For example - to test on arm64 devices with clang:
# $NDK/build/tools/make_standalone_toolchain.py \
# --arch arm64 --install-dir=/tmp/my-android-toolchain
# export PATH=/tmp/my-android-toolchain/bin:$PATH
# CROSS=aarch64-linux-android- CC=clang CXX=clang++ /path/to/libvpx/configure \
# --target=arm64-android-gcc
Note the CROSS/CC settings
AS mentioned though, this has been a difficult path to maintain. I'd prefer to remove it:
jo...@google.com
The initial issue with avx2 detection has been addressed.
If you are still having issues please open a new bug.
If you are still having issues please open a new bug.
cm...@gmail.com
Yes, the problem is resolved with option "--enable-runtime-cpu-detect" ; you may close the issue.
May be you would consider to include this info into your documentation.
I excluded this option in all aTalk JNI libraries built to reduce size; may not have caught the problem as the built gives no problem.
May be you would consider to include this info into your documentation.
I excluded this option in all aTalk JNI libraries built to reduce size; may not have caught the problem as the built gives no problem.
bu...@chops-service-accounts.iam.gserviceaccount.com
The following revision refers to this bug:
https://chromium.googlesource.com/webm/libvpx/+/6522c56c8c03119ba78277f0805c09aeb64c8d30
commit 6522c56c8c03119ba78277f0805c09aeb64c8d30
Author: Johann <johannkoenig@google.com>
Date: Mon May 06 19:48:50 2019
android: clarify RTCD usage
Note that when using --disable-runtime-cpu-detect the developer
must keep in mind what devices the library will be run on.
BUG=webm:1623
Change-Id: I0359e226bb678f8e5145bb30cd1cefc7e30c6c79
[modify]https://crrev.com/6522c56c8c03119ba78277f0805c09aeb64c8d30/build/make/Android.mk
commit 6522c56c8c03119ba78277f0805c09aeb64c8d30
Author: Johann <johannkoenig@google.com>
Date: Mon May 06 19:48:50 2019
android: clarify RTCD usage
Note that when using --disable-runtime-cpu-detect the developer
must keep in mind what devices the library will be run on.
BUG=webm:1623
Change-Id: I0359e226bb678f8e5145bb30cd1cefc7e30c6c79
[modify]
Description
What is the expected behavior? What do you see instead?
https://bugs.chromium.org/p/webm/issues/detail?id=1622&can=4&q=&colspec=ID%20Pri%20mstone%20ReleaseBlock%20Type%20Component%20Status%20Owner%20Summary
After applying patch as in:
Build all libvpx forABIS=("armeabi-v7a" "arm64-v8a" "x86" "x86_64") and integrate with aTalk.
Test devices for aTalk using libvpx as the video codec (VP8)
#a. Note 5: android 5.0 (armeabi-v7a)
#b. Note 8: android 9.0 (arm64-v8a)
#c. AVD pixel-2-API-28: android 9.0 (x86_64)
There is no problem in video call setup between device #a and #b using VP8 as video codec. However when a video call is setup between #b and #c, following problems are observed:
Upon video call connected, device #c is able to show both the send (preview) and received videos as shown in the attached png file. However second later aTalk crashes and restart. I have captured the debug logcat for device #c as shown below. It seems that fmj did successfully setup both the VPX encoder and decoder. However second later it throws "Fatal signal 4 (SIGILL)" apparently due the VPX encoder (There is no vp8 video stream received on device #b), probably due to x86_64 assembly coding error.
Note:
a. when using x264 as video codec, there is no problem with the video call setup between device #b and device #c.
b. I faced a similar problem in ffmpeg library in aTalk; ffmpeg has
--disable-asm option to omit asm coding, I used this option to fix ffmpeg fault on x86_64 platform.
What version are you using? On what operating system?
libvpx master repository source (20190415), v1.8.0, v1.7.0 and v1.6.1 etc, using android ndk-r15c on ubuntu 18.04
Can you reproduce using the vpxdec or vpxenc tools? What command line are
you using?
Only tested using aTalk app
Please provide any additional information below.
https://github.com/cmeng-git/atalk-android
libvpx is used in aTalk project for the various android ABIS i.e.
ABIS=("armeabi-v7a" "arm64-v8a" "x86" "x86_64")
You may refer to following site for more information.
aTalk is also available in the google playstore
Current aTalk v1.8.1 in playstore is using vpx v1.6.1+
Below is the captured debug logcat on AVD pixel-2_API-28 (x86_64)
========= VP8 decoder setup ==========
2019-04-15 11:15:02.970 20363-20734/org.atalk.android D/aTalk: [969] net.sf.fmj.media.Log.comment() Input: VP8/RTP, fmtps={}
2019-04-15 11:15:02.984 20363-20734/org.atalk.android D/(VPXDecoder.java:124)#doOpen: VP8 decoder opened successfully
2019-04-15 11:15:02.987 20363-20734/org.atalk.android D/aTalk: [969] net.sf.fmj.media.Log.write()
2019-04-15 11:15:02.989 20363-20734/org.atalk.android D/aTalk: [969] net.sf.fmj.media.Log.comment() Here's the completed flow graph:
2019-04-15 11:15:02.990 20363-20734/org.atalk.android D/aTalk: [969] net.sf.fmj.media.Log.write() net.sf.fmj.media.parser.RawPushBufferParser@cf3929c
2019-04-15 11:15:02.996 20363-20734/org.atalk.android D/aTalk: [969] net.sf.fmj.media.Log.write() connects to: org.atalk.impl.neomedia.codec.video.vp8.DePacketizer@b0924a5
2019-04-15 11:15:02.997 20363-20734/org.atalk.android D/aTalk: [969] net.sf.fmj.media.Log.write() format: VP8/RTP, fmtps={}
2019-04-15 11:15:02.998 20363-20734/org.atalk.android D/aTalk: [969] net.sf.fmj.media.Log.write() org.atalk.impl.neomedia.codec.video.vp8.DePacketizer@b0924a5
2019-04-15 11:15:03.002 20363-20734/org.atalk.android D/aTalk: [969] net.sf.fmj.media.Log.write() connects to: org.atalk.impl.neomedia.codec.video.vp8.VPXDecoder@8ad107a
2019-04-15 11:15:03.005 20363-20734/org.atalk.android D/aTalk: [969] net.sf.fmj.media.Log.write() format: VP8
2019-04-15 11:15:03.006 20363-20734/org.atalk.android D/aTalk: [969] net.sf.fmj.media.Log.write() org.atalk.impl.neomedia.codec.video.vp8.VPXDecoder@8ad107a
2019-04-15 11:15:03.007 20363-20734/org.atalk.android D/aTalk: [969] net.sf.fmj.media.Log.write() connects to: org.atalk.impl.neomedia.codec.video.SwScale@4cdab6e
2019-04-15 11:15:03.008 20363-20734/org.atalk.android D/aTalk: [969] net.sf.fmj.media.Log.write() format: AVFRAME, class org.atalk.impl.neomedia.codec.video.AVFrame, pixFmt 0
2019-04-15 11:15:03.010 20363-20734/org.atalk.android D/aTalk: [969] net.sf.fmj.media.Log.write() org.atalk.impl.neomedia.codec.video.SwScale@4cdab6e
2019-04-15 11:15:03.011 20363-20734/org.atalk.android D/aTalk: [969] net.sf.fmj.media.Log.write() connects to: org.atalk.impl.neomedia.jmfext.media.renderer.video.JAWTRenderer@ae1b20f
2019-04-15 11:15:03.011 20363-20734/org.atalk.android D/aTalk: [969] net.sf.fmj.media.Log.write() format: RGB, 32-bit, Masks=255:65280:16711680, LineStride=-1, class [I
2019-04-15 11:15:03.012 20363-20734/org.atalk.android D/aTalk: [969] net.sf.fmj.media.Log.write()
2019-04-15 11:15:03.013 20363-20734/org.atalk.android D/aTalk: [969] net.sf.fmj.media.Log.profile() Profile: graph building: 43 ms
2019-04-15 11:15:03.013 20363-20734/org.atalk.android D/aTalk: [969] net.sf.fmj.media.Log.profile() Profile: realize, post graph building: 0 ms
========= VP8 encoder setup ==========
2019-04-15 11:15:03.046 20363-20732/org.atalk.android I/(CameraStreamBase.java:130)#startImpl: Camera stream format: YUV Video Format: Size = [width=720, height=1280] MaxDataLength = -1 DataType = class [B yuvType = -1 StrideY = -1 StrideUV = -1 OffsetY = -1 OffsetU = -1 OffsetV = -1
2019-04-15 11:15:03.048 20363-20732/org.atalk.android I/(PreviewStream.java:89)#onInitPreview: Camera captured preview = 1280x720 @90-DEG with buffer size: 1392640 for image format: 32315659
2019-04-15 11:15:03.053 20363-20760/org.atalk.android D/aTalk: [977] net.sf.fmj.media.Log.comment() net.sf.fmj.media.BasicFilterModule@ff53c88: input format changed: AVFRAME, 720x960, class org.atalk.impl.neomedia.codec.video.AVFrame, pixFmt 0
2019-04-15 11:15:03.091 20363-20732/org.atalk.android D/aTalk: [967] net.sf.fmj.media.Log.profile() Profile: parsing: 124 ms
2019-04-15 11:15:03.301 20363-20728/org.atalk.android D/aTalk: [962] net.sf.fmj.media.Log.comment() Getting the supported output formats for:
2019-04-15 11:15:03.302 20363-20728/org.atalk.android D/aTalk: [962] net.sf.fmj.media.Log.comment() YUV Video Format: Size = [width=720, height=1280] MaxDataLength = -1 DataType = class [B yuvType = -1 StrideY = -1 StrideUV = -1 OffsetY = -1 OffsetU = -1 OffsetV = -1
2019-04-15 11:15:03.303 20363-20728/org.atalk.android D/aTalk: [962] net.sf.fmj.media.Log.comment() # of nodes visited: 27
2019-04-15 11:15:03.304 20363-20728/org.atalk.android D/aTalk: [962] net.sf.fmj.media.Log.comment() # of formats supported: 17
2019-04-15 11:15:03.305 20363-20728/org.atalk.android D/aTalk: [962] net.sf.fmj.media.Log.profile() Profile: getSupportedOutputFormats: 212 ms
2019-04-15 11:15:03.380 20363-20771/org.atalk.android D/aTalk: [979] net.sf.fmj.media.Log.comment() Building flow graph for: null
2019-04-15 11:15:03.399 20363-20771/org.atalk.android D/aTalk: [979] net.sf.fmj.media.Log.comment() Building Track: 0
2019-04-15 11:15:06.291 20363-20771/org.atalk.android D/aTalk: [979] net.sf.fmj.media.Log.comment() Input: YUV Video Format: Size = [width=720, height=1280] MaxDataLength = -1 DataType = class [B yuvType = -1 StrideY = -1 StrideUV = -1 OffsetY = -1 OffsetU = -1 OffsetV = -1
2019-04-15 11:15:06.291 20363-20771/org.atalk.android D/aTalk: [979] net.sf.fmj.media.Log.comment() Custom options specified.
2019-04-15 11:15:06.292 20363-20771/org.atalk.android D/aTalk: [979] net.sf.fmj.media.Log.comment() An output format is specified: VP8/RTP
2019-04-15 11:15:06.292 20363-20771/org.atalk.android D/aTalk: [979] net.sf.fmj.media.Log.comment() An output content type is specified: raw.rtp
2019-04-15 11:15:06.666 20363-20725/org.atalk.android W/g.atalk.androi: JNI critical lock held for 279.284ms on Thread[154,tid=20725,Runnable,Thread*=0x77b2b58e1000,peer=0x13941828,"Loop thread: net.sf.fmj.media.parser.RawPullBufferParser$FrameTrack@8183341"]
2019-04-15 11:15:07.370 20363-20759/org.atalk.android D/aTalk: [970] net.sf.fmj.media.Log.comment() net.sf.fmj.media.BasicRendererModule@da8435d: input format changed: RGB, 720x960, 32-bit, Masks=255:65280:16711680, LineStride=720, class [I
2019-04-15 11:15:07.376 20363-20665/org.atalk.android W/g.atalk.androi: Verification of void net.sf.fmj.media.rtp.RTCPSenderReport.<init>(byte[], int, int) took 337.617ms
2019-04-15 11:15:07.417 20363-20717/org.atalk.android D/aTalk: [952] net.sf.fmj.media.Log.comment() RTP video buffer size: 36 pkts, 19251 bytes.
2019-04-15 11:15:07.783 20363-20725/org.atalk.android W/g.atalk.androi: JNI critical lock held for 355.944ms on Thread[154,tid=20725,Runnable,Thread*=0x77b2b58e1000,peer=0x13941828,"Loop thread: net.sf.fmj.media.parser.RawPullBufferParser$FrameTrack@8183341"]
2019-04-15 11:15:08.136 20363-20771/org.atalk.android D/(VPXEncoder.java:199)#doOpen: VP8 encoder opened successfully
2019-04-15 11:15:08.142 20363-20771/org.atalk.android D/aTalk: [979] net.sf.fmj.media.Log.write()
2019-04-15 11:15:08.144 20363-20725/org.atalk.android W/g.atalk.androi: JNI critical lock held for 307.921ms on Thread[154,tid=20725,Runnable,Thread*=0x77b2b58e1000,peer=0x13941828,"Loop thread: net.sf.fmj.media.parser.RawPullBufferParser$FrameTrack@8183341"]
2019-04-15 11:15:08.155 20363-20771/org.atalk.android D/aTalk: [979] net.sf.fmj.media.Log.comment() Here's the completed flow graph:
2019-04-15 11:15:08.156 20363-20771/org.atalk.android D/aTalk: [979] net.sf.fmj.media.Log.write() net.sf.fmj.media.parser.RawPushBufferParser@c1934d2
2019-04-15 11:15:08.157 20363-20771/org.atalk.android D/aTalk: [979] net.sf.fmj.media.Log.write() connects to: org.atalk.impl.neomedia.codec.video.vp8.VPXEncoder@13fa9a3
2019-04-15 11:15:08.157 20363-20771/org.atalk.android D/aTalk: [979] net.sf.fmj.media.Log.write() format: YUV Video Format: Size = [width=720, height=1280] MaxDataLength = -1 DataType = class [B yuvType = -1 StrideY = -1 StrideUV = -1 OffsetY = -1 OffsetU = -1 OffsetV = -1
2019-04-15 11:15:08.538 20363-20725/org.atalk.android W/g.atalk.androi: JNI critical lock held for 361.703ms on Thread[154,tid=20725,Runnable,Thread*=0x77b2b58e1000,peer=0x13941828,"Loop thread: net.sf.fmj.media.parser.RawPullBufferParser$FrameTrack@8183341"]
2019-04-15 11:15:08.547 20363-20771/org.atalk.android D/aTalk: [979] net.sf.fmj.media.Log.write() org.atalk.impl.neomedia.codec.video.vp8.VPXEncoder@13fa9a3
2019-04-15 11:15:08.548 20363-20771/org.atalk.android D/aTalk: [979] net.sf.fmj.media.Log.write() connects to: org.atalk.impl.neomedia.codec.video.vp8.Packetizer@4dd14a0
2019-04-15 11:15:08.549 20363-20771/org.atalk.android D/aTalk: [979] net.sf.fmj.media.Log.write() format: VP8, 720x1280, FrameRate=2.0
2019-04-15 11:15:08.549 20363-20771/org.atalk.android D/aTalk: [979] net.sf.fmj.media.Log.write() org.atalk.impl.neomedia.codec.video.vp8.Packetizer@4dd14a0
2019-04-15 11:15:08.550 20363-20771/org.atalk.android D/aTalk: [979] net.sf.fmj.media.Log.write() connects to: com.sun.media.multiplexer.RTPSyncBufferMux@22ab859
2019-04-15 11:15:08.551 20363-20771/org.atalk.android D/aTalk: [979] net.sf.fmj.media.Log.write() format: VP8/RTP
2019-04-15 11:15:08.551 20363-20771/org.atalk.android D/aTalk: [979] net.sf.fmj.media.Log.write()
2019-04-15 11:15:08.552 20363-20771/org.atalk.android D/aTalk: [979] net.sf.fmj.media.Log.profile() Profile: graph building: 5171 ms
2019-04-15 11:15:08.553 20363-20771/org.atalk.android D/aTalk: [979] net.sf.fmj.media.Log.profile() Profile: realize, post graph building: 0 ms
2019-04-15 11:15:09.354 20363-20723/org.atalk.android I/(VideoMediaDeviceSession.java:1022)#playerSizeChange: Size Change Video Event: 720x960
============= SIGILL fault =============
2019-04-15 11:15:18.821 20363-20780/org.atalk.android A/libc: Fatal signal 4 (SIGILL), code 2 (ILL_ILLOPN), fault addr 0x77b2ac1757e6 in tid 20780 (Loop thread: ne), pid 20363 (g.atalk.android)
2019-04-15 11:15:22.986 20790-20790/? A/DEBUG: pid: 20363, tid: 20780, name: Loop thread: ne >>> org.atalk.android <<<
2019-04-15 11:15:23.383 20363-20725/org.atalk.android W/g.atalk.androi: JNI critical lock held for 308.333ms on Thread[154,tid=20725,Runnable,Thread*=0x77b2b58e1000,peer=0x13941828,"Loop thread: net.sf.fmj.media.parser.RawPullBufferParser$FrameTrack@8183341"]
2019-04-15 11:15:23.940 20790-20790/? A/DEBUG: #00 pc 000000000006b7e6 /data/app/org.atalk.android-FWd-5MB3PUUGjFQEiqJy0A==/lib/x86_64/libjnvpx.so (vpx_variance16x16_avx2+6)
2019-04-15 11:15:23.940 20790-20790/? A/DEBUG: #01 pc 00000000000233e3 /data/app/org.atalk.android-FWd-5MB3PUUGjFQEiqJy0A==/lib/x86_64/libjnvpx.so (vp8_pick_intra_mode+131)
2019-04-15 11:15:23.940 20790-20790/? A/DEBUG: #02 pc 000000000007bdb2 /data/app/org.atalk.android-FWd-5MB3PUUGjFQEiqJy0A==/lib/x86_64/libjnvpx.so (vp8cx_encode_intra_macroblock+50)
2019-04-15 11:15:23.940 20790-20790/? A/DEBUG: #03 pc 000000000007b6af /data/app/org.atalk.android-FWd-5MB3PUUGjFQEiqJy0A==/lib/x86_64/libjnvpx.so
2019-04-15 11:15:23.940 20790-20790/? A/DEBUG: #04 pc 000000000007a866 /data/app/org.atalk.android-FWd-5MB3PUUGjFQEiqJy0A==/lib/x86_64/libjnvpx.so (vp8_encode_frame+1542)
2019-04-15 11:15:23.940 20790-20790/? A/DEBUG: #05 pc 000000000001b64f /data/app/org.atalk.android-FWd-5MB3PUUGjFQEiqJy0A==/lib/x86_64/libjnvpx.so (vp8_get_compressed_data+7103)
2019-04-15 11:15:23.940 20790-20790/? A/DEBUG: #06 pc 0000000000014c34 /data/app/org.atalk.android-FWd-5MB3PUUGjFQEiqJy0A==/lib/x86_64/libjnvpx.so
2019-04-15 11:15:23.940 20790-20790/? A/DEBUG: #07 pc 000000000001391d /data/app/org.atalk.android-FWd-5MB3PUUGjFQEiqJy0A==/lib/x86_64/libjnvpx.so (vpx_codec_encode+141)
2019-04-15 11:15:23.940 20790-20790/? A/DEBUG: #08 pc 0000000000012bec /data/app/org.atalk.android-FWd-5MB3PUUGjFQEiqJy0A==/lib/x86_64/libjnvpx.so (Java_org_atalk_impl_neomedia_codec_video_VPX_codec_1encode+124)
2019-04-15 11:15:23.940 20790-20790/? A/DEBUG: #16 pc 0000000000255342 /dev/ashmem/dalvik-classes.dex extracted in memory from /data/app/org.atalk.android-FWd-5MB3PUUGjFQEiqJy0A==/base.apk (deleted) (org.atalk.impl.neomedia.codec.video.vp8.VPXEncoder.doProcess+434)
2019-04-15 11:15:23.941 20790-20790/? A/DEBUG: #22 pc 0000000000208f38 /dev/ashmem/dalvik-classes.dex extracted in memory from /data/app/org.atalk.android-FWd-5MB3PUUGjFQEiqJy0A==/base.apk (deleted) (org.atalk.impl.neomedia.codec.AbstractCodec2.process+100)
2019-04-15 11:15:23.945 20790-20790/? A/DEBUG: #28 pc 00000000003f9d10 /dev/ashmem/dalvik-classes2.dex extracted in memory from /data/app/org.atalk.android-FWd-5MB3PUUGjFQEiqJy0A==/base.apk!classes2.dex (deleted) (net.sf.fmj.media.BasicFilterModule.process+620)
2019-04-15 11:15:23.946 20790-20790/? A/DEBUG: #34 pc 00000000003fa800 /dev/ashmem/dalvik-classes2.dex extracted in memory from /data/app/org.atalk.android-FWd-5MB3PUUGjFQEiqJy0A==/base.apk!classes2.dex (deleted) (net.sf.fmj.media.BasicModule.connectorPushed)
2019-04-15 11:15:23.953 20790-20790/? A/DEBUG: #40 pc 00000000003fbb44 /dev/ashmem/dalvik-classes2.dex extracted in memory from /data/app/org.atalk.android-FWd-5MB3PUUGjFQEiqJy0A==/base.apk!classes2.dex (deleted) (net.sf.fmj.media.BasicOutputConnector.writeReport+128)
2019-04-15 11:15:23.953 20790-20790/? A/DEBUG: #46 pc 0000000000409d90 /dev/ashmem/dalvik-classes2.dex extracted in memory from /data/app/org.atalk.android-FWd-5MB3PUUGjFQEiqJy0A==/base.apk!classes2.dex (deleted) (net.sf.fmj.media.SourceThread.process+700)
2019-04-15 11:15:23.954 20790-20790/? A/DEBUG: #52 pc 0000000000442568 /dev/ashmem/dalvik-classes2.dex extracted in memory from /data/app/org.atalk.android-FWd-5MB3PUUGjFQEiqJy0A==/base.apk!classes2.dex (deleted) (net.sf.fmj.media.util.LoopThread.run+20)