Native crash in FFmpegFrameRecorder.recordSamples() when using RTMPS connection

[scorpeeon]

I'm using this lib to decode sound from microphone to aac and stream it through RTMP(S) to a server. For this I'm using FFmpegFrameRecorder.recordSamples() function and it is working fine when I'm connecting through a normal RTMP connection. But when I'm using RTMPS, it also works fine for the initial 2-3 seconds (and I can playback this little part on the server) but after that the native part just crashes with a not very verbose message:

E/audit: type=1701 msg=audit(1461335772.791:1017): auid=4294967295 uid=10325 gid=10325 ses=4294967295 subj=u:r:untrusted_app:s0:c512,c768 pid=23492 comm="pool-4-thread-1" reason="memory violation" sig=11

When debugging I found that this happens a few seconds after initiating the connection precisely when returning from the recordSamples() function. (initially I thought that the last line was crashing but I modified it and it still crashed when it returned from this function).

Since the crash message is not very verbose and the said function is over a 100 lines with quite a few native calls, I don't really know how to debug this issue. Any ideas?

[saudet]

Please try again with the latest SNAPSHOT binaries available here:
https://oss.sonatype.org/content/repositories/snapshots/org/bytedeco/javacpp/1.2-SNAPSHOT/
https://oss.sonatype.org/content/repositories/snapshots/org/bytedeco/javacpp-presets/ffmpeg/3.0-1.2-SNAPSHOT/
https://oss.sonatype.org/content/repositories/snapshots/org/bytedeco/javacv/1.2-SNAPSHOT/

[scorpeeon]

I tried it with those, and the same thing happens.
I also rebuilt javacpp-presets and javacv from source (and even changed the last line in the said javacv function as I thought it caused the crash but it wasn't the case apparently) and the same thing is happening..

One strange thing I noticed is that while this function normally runs around 24 times before crashing (producing the 2-3 second sound on the server), if I put a breakpoint to the function's beginning and make the program wait at least a few seconds there, it actually crashes the first time it would return from it. So it's like it's something external/asynchronous that's causing this - but I don't know what can it be as I don't call ffmpeg related functions elsewhere... Might be something about the network connection? (it would make sense as it works fine just by changing rtmps to rtmp) I really don't know...

[saudet]

Does the same thing happen in another OS?

[scorpeeon]

That's a good question, I didn't test that yet. It's used in an Android app currently.
I might try to make a basic Java project to test that.

[scorpeeon]

It looks like it's working through the normal desktop java console app on windows (x86_64), I managed to stream a 10 second audio without problems.
So the error is something Android specific it seems? Really strange...

[saudet]

I think the Windows binaries were built with GnuTLS instead of OpenSSL though.

[scorpeeon]

That's interesting, I might try to build a version that uses GnuTLS..

Meanwhile an interesting observation: I made the aforementioned minimalist app work on Android (to exclude all other sources of errors) and this time, there's no error, in runs through, but a 10 second sample takes around 3 minutes to process. I did some logging, and the first ~3 second go normally, then it gets blocked in recordSamples() for around a whole minute (!) (around 56 seconds to be precise) then it continues as if nothing happened when after a further ~3 seconds, the same 1 minute long blocking happens, etc.
The actual error was probably cased by other codes in the project (which used the lib through RxJava) which assumed it would run in around real-time and no minute-long blocking happen meanwhile. In the end the result is on the server in a 10 second sample, the only problem is that it can't really be used in any real-time applications this way because of the long blockings...

So apparently it looks like it

1. start off/continue fine
2. get stuck after ~ 3-4 seconds
3. when reaching a minute (3-4 seconds normal processing + 56 seconds blocking) -> repeat from 1

It must be something network/protocol related... Like the connection or something gets reset every minute or something - which makes it continue that gets otherwise blocked after a few seconds.

[scorpeeon]

I see the script in javacpp-presets that builds ffmpeg (cppbuild.sh) is only made to build with OpenSSL and for Windows it uses Zeranoe's builds which has GnuTLS already integrated so that's of little help.

Any tip about how to build it with GnuTLS? I'm really noob in this, and I'm unsure about how to get started. What I'm unsure about is if I somehow manage to separately compile GnuTLS for Android (using RTMPDump or similar) - or even better FFMPEG with GnuTLS for Android - can I just put it in this lib (in the place of the corresponding .so file that currently has openssl - I'm not even sure which one is it) and make it work with minimal additional work? Or it's not so simple and I'm better off building "from scratch" and modifying this script to compile gnutls insted of openssl (if I figure out howto do that)?

[saudet]

Sure, if you get a build with GnuTLS, the rest is easy. The hard part is getting the build working...

[scorpeeon]

Yeah, thanks, I'll try to do that - though I assume it really won't be easy and I'm not even sure where to start...
BTW it looks like the precompiled binaries for Android are for armv5, is this intentional? As I understand, pretty much all devices today are armv7 compatible and armv5 is lacking pretty basic things like floating point unit support which can cause a huge performance difference...

[scorpeeon]

Some very interesting new findings:
It looks like the issue is not present in javacv release 0.11 (it's present on 1.0 and onwards).
On 0.11, rtmps streaming is working fine on android.

(I compiled javacpp-presets + javacv with newer ffmpeg (3.0.2) and openssl (1.0.2h) and it was still broken that's why I starting digging into older versions and since I got various compile errors I got tired with I just tried the archived releases - I'm really unsure where the problem might be)

[saudet]

Nothing special happened at the release of version 1.0. If you figure out how to fix that, please let me know! Thanks

[scorpeeon]

I checked and between 0.11 and 1.0 at the first glance I see:
-8 commits in javacpp-presets
-4 commits in javacv
that has changes related to ffmpeg/openssl. (Well, it could be in javacpp too..) And the issue is probably only in one repo of the 2 (or 3), so it shouldn't take too long to test out which commit is to blame..
Well, javacv compiles fairly quickly, but javacpp-presets can take pretty long (took more than on hour on my machine from which ffmpeg took like 15 minutes).

I'll try to check with the changes reverted in javacv but if it's in the other 2 repos, I'm not sure I can check them because of the compile times.

[saudet]

Great, thanks for testing that! BTW, it's possible to limit the presets to build only ffmpeg with a command like mvn clean install -pl .,ffmpeg.