"avcodec_find_encoder() error: Audio codec not found." error after compiling on Linux

[Pete Helgren]

I think I have everything compiled correctly now.  I was thrown initially by the change in package names.  I went back to my Windows install which does work correctly, installed the new jars with the new package names and then re-created my jar file to run.  The javacpp-presets seemed to work OK and I do have content in every jar with no errors.  But, I get a "org.bytedeco.javacv.FrameRecorder$Exception: avcodec_find_encoder() error: Audio codec not found."

Here is how I invoke the code:

java -cp bsfmlt.jar:javacpp.jar:javacv.jar:opencv.jar:ffmpeg.jar:log4j-1.2.16.jar:ffmpeg-linux-x86_64.jar:opencv-linux-x86_64.jar  org.bsfinternational.utils.LoadTestAudioMerge /var/bsf/lectureFiles 20 5

The  ffmpeg.jar, ffmpeg-linux-x86_64.jar, javacpp.jar,opencv.jar and opencv-linux-x86_64.jar were all in the "target" folder after the "mvn install" command completed but it looks like the codecs are missing(?)  Should they be in one of the .jar files? Or, should it be in the path or libs in the Linux environment?

Again...it seems I am pretty close to getting this done.  ffmpeg at the command line shows this:

[root@402618-test loadtest]# ffmpeg

ffmpeg version 2.2.1 Copyright (c) 2000-2014 the FFmpeg developers

  built on May 28 2014 10:54:14 with gcc 4.2.0 (GCC)

  configuration: --enable-shared --enable-gpl --enable-version3 --enable-runtime-cpudetect --disable-outdev=sdl --enable-libx264 --extra-cflags=-Ix264-snapshot-20140527-2245-stable --extra-ldflags=-Lx264-snapshot-20140527-2245-stable --extra-ldflags=-ldl --libdir=/usr/local/lib64/ --shlibdir=/usr/local/lib64/

  WARNING: library configuration mismatch

  avutil      configuration: --prefix=/root/ffmpeg_build --extra-cflags=-I/root/ffmpeg_build/include --extra-ldflags=-L/root/ffmpeg_build/lib --bindir=/root/bin --extra-libs=-ldl --enable-gpl --enable-nonfree --enable-shared --enable-libfdk_aac --enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libvpx --enable-libx264

  avcodec     configuration: --prefix=/root/ffmpeg_build --extra-cflags=-I/root/ffmpeg_build/include --extra-ldflags=-L/root/ffmpeg_build/lib --bindir=/root/bin --extra-libs=-ldl --enable-gpl --enable-nonfree --enable-shared --enable-libfdk_aac --enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libvpx --enable-libx264

  avformat    configuration: --prefix=/root/ffmpeg_build --extra-cflags=-I/root/ffmpeg_build/include --extra-ldflags=-L/root/ffmpeg_build/lib --bindir=/root/bin --extra-libs=-ldl --enable-gpl --enable-nonfree --enable-shared --enable-libfdk_aac --enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libvpx --enable-libx264

  avdevice    configuration: --prefix=/root/ffmpeg_build --extra-cflags=-I/root/ffmpeg_build/include --extra-ldflags=-L/root/ffmpeg_build/lib --bindir=/root/bin --extra-libs=-ldl --enable-gpl --enable-nonfree --enable-shared --enable-libfdk_aac --enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libvpx --enable-libx264

  avfilter    configuration: --prefix=/root/ffmpeg_build --extra-cflags=-I/root/ffmpeg_build/include --extra-ldflags=-L/root/ffmpeg_build/lib --bindir=/root/bin --extra-libs=-ldl --enable-gpl --enable-nonfree --enable-shared --enable-libfdk_aac --enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libvpx --enable-libx264

  swscale     configuration: --prefix=/root/ffmpeg_build --extra-cflags=-I/root/ffmpeg_build/include --extra-ldflags=-L/root/ffmpeg_build/lib --bindir=/root/bin --extra-libs=-ldl --enable-gpl --enable-nonfree --enable-shared --enable-libfdk_aac --enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libvpx --enable-libx264

  swresample  configuration: --prefix=/root/ffmpeg_build --extra-cflags=-I/root/ffmpeg_build/include --extra-ldflags=-L/root/ffmpeg_build/lib --bindir=/root/bin --extra-libs=-ldl --enable-gpl --enable-nonfree --enable-shared --enable-libfdk_aac --enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libvpx --enable-libx264

  postproc    configuration: --prefix=/root/ffmpeg_build --extra-cflags=-I/root/ffmpeg_build/include --extra-ldflags=-L/root/ffmpeg_build/lib --bindir=/root/bin --extra-libs=-ldl --enable-gpl --enable-nonfree --enable-shared --enable-libfdk_aac --enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libvpx --enable-libx264

  libavutil      52. 66.100 / 52. 85.100

  libavcodec     55. 52.102 / 55. 63.100

  libavformat    55. 33.100 / 55. 38.101

  libavdevice    55. 10.100 / 55. 13.101

  libavfilter     4.  2.100 /  4.  5.100

  libswscale      2.  5.102 /  2.  6.100

  libswresample   0. 18.100 /  0. 19.100

  libpostproc    52.  3.100 / 52.  3.100

Hyper fast Audio and Video encoder

usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}...

The WARNING makes me a little nervous and the fact that only  --enable-libx264 flag is listed but that should only affect the command line version, correct?  It *looks* like all the other libs are compiled and linked.

Suggestions?

[Pete Helgren]

OK!  So I have this working (somewhat).  I hacked the cppbuild.sh script for ffmpeg and added the following:

 --enable-libmp3lame --enable-libvorbis --enable-libvpx

To the ,/configure line for both the linux x86 and the linux 86_x64 sections and those codec's were added after I re-ran the mvn install command.   But now I have a new problem.  I get a SIGSEGV fault in the JVM while this is running.  It appears to be a memory leak, although I can't be sure.  The reason I suspect a memory leak is because the the fault occurs much more quickly when I spin up multiple threads of the process in my app. Here is a bit more information:

#

# A fatal error has been detected by the Java Runtime Environment:

#

#  SIGSEGV (0xb) at pc=0x00002b64fc47d48b, pid=22797, tid=47712546933056

#

# JRE version: 6.0_26-b03

# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.1-b02 mixed mode linux-amd64 co

# Problematic frame:

# C  [libswresample.so.0+0x448b]  signed char+0x448b

Not sure where that occurs in libswresample but that is the information I have.  I can send the entire log if necessary.

Seems like every problem I solve, I get yet more more issue......

[Samuel Audet]

Seems more like a threading issue to me. I'd venture that libswresample
probably isn't thread safe and we'd have to add guards at least when
creating a new context. You haven't tried the same under Windows with
multiple threads by any chance, have you?

> Seems like every problem I solve, I get yet more more issue......

We'll get there, eventually :)

Samuel

[Pete Helgren]

On Windows I use the exact same Java code without any errors.  Basically I have a Java program that launches a thread (a class the implements runnable and then a run method).  The thread runs the merge code that we sorted out a few weeks ago.  Right now I am working to prove that all will be well when it runs on Linux (RH5 EL) which so far hasn't gone well.... 

The Java program was written to take a couple of parameters which will help me load test the Linux server when I finally get this to run.  The parameters basically determine how many times the test of the merge will run and how long to wait before each thread is spun up.  I can run 30 threads about 5 seconds apart that will take about 20 minutes to encode and merge 30 files of about 60mb in size.  This runs flawlessly in windows.  In Linux, even if I choose to only run one thread, the program eventually dies, even with one thread.  It seems to work fine until just about the end of the merge cycle. There IS a merged file at the end of the process but the JVM being dead makes it a challenge to figure out what went wrong and at what point.

To refresh your memory, this is the code that is running in a thread (stripped of some debugging statements):

// Just a basic test to start: This will merge the "intro" file with the "lecture file

// input 1 and 2 are string values with the full path and file name

FrameGrabber intro = new FFmpegFrameGrabber(input1); 

FrameGrabber lecture = new FFmpegFrameGrabber(input2);

 

try {

         

intro.start();

FrameRecorder recorder = new FFmpegFrameRecorder(output,1); 

recorder.setSampleFormat(intro.getSampleFormat()); 

recorder.setSampleRate(intro.getSampleRate());

recorder.setAudioChannels(intro.getAudioChannels());

recorder.setAudioBitrate(64000);

recorder.start();

Frame frame; 

while ((frame = intro.grabFrame()) != null) { 

    recorder.record(frame);

} 

i

intro.stop();

lecture.start();

while ((frame = lecture.grabFrame()) != null) {

recorder.record(frame); 

} 

lecture.stop();

recorder.stop(); 

} catch (Exception e) {

// TODO Auto-generated catch block

e.printStackTrace();

}   

}

I am not sure where the JVM falls over but again, this works like a charm with the windows libs you provide.

[Pete Helgren]

And this additional bit:

I decided that perhaps my RH5 distro was to blame so I decided to install a CentOS 5 VM and compile there.  All goes well (well, not *well" but I was able to finally compile everything) it all goes well until I run the mvn install command in the javacpp-presets folder.  Opencv builds fine but when it gets to ffmpeg I see this:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3:compile (default-compile) on project ffmpeg: Compilation failure: Compilation failure:

[ERROR] /root/ffmpeg_sources/javacpp-presets/ffmpeg/src/main/java/org/bytedeco/javacpp/avutil.java:[4240,51] cannot find symbol

[ERROR] symbol  : class FF_CONST_AVUTIL53

[ERROR] location: class org.bytedeco.javacpp.avutil

[ERROR] 

I don't know what it is referring to.  Yet another roadblock.....

I was hoping a "clean" distro and a completely new fresh installation of tools would fix the issue but as usual, the issues with compiling are many and varied.

So, I hope you can help out with one or both of these issues.

[Samuel Audet]

On 06/03/2014 05:28 AM, Pete Helgren wrote:
> And this additional bit:
>
> I decided that perhaps my RH5 distro was to blame so I decided to
> install a CentOS 5 VM and compile there. All goes well (well, not
> *well" but I was able to finally compile everything) it all goes well
> until I run the mvn install command in the javacpp-presets folder.
> Opencv builds fine but when it gets to ffmpeg I see this:
>
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3:compile (default-compile) on project ffmpeg: Compilation failure: Compilation failure:
> [ERROR] /root/ffmpeg_sources/javacpp-presets/ffmpeg/src/main/java/org/bytedeco/javacpp/avutil.java:[4240,51] cannot find symbol
> [ERROR] symbol : class FF_CONST_AVUTIL53
> [ERROR] location: class org.bytedeco.javacpp.avutil
> [ERROR]
>
> I don't know what it is referring to. Yet another roadblock.....
>
> I was hoping a "clean" distro and a completely new fresh installation of
> tools would fix the issue but as usual, the issues with compiling are
> many and varied.
>
> So, I hope you can help out with one or both of these issues.

Have you used the cppbuild.sh script to build that version of FFmpeg? It
shouldn't happen if you used that, but if you used whatever random
version of FFmpeg that comes with the distro, who knows what might happen...

BTW, if the distro is recent enough, you can probably use my binaries
without having to rebuild anything.

Samuel

[Pete Helgren]

So I have to stick with CentOS 5 because the binaries will be compatible with RH5 which has to be the target OS.  I haven't tried your binaries because I assumed that I would have the same issue with CentOS5 as RH5..

I am following your installation instructions step by step.  The only variable things are the libs that are getting enabled in the ffmpeg build.  These are the libs I am currently compiling into ffmpeg:

[root@localhost javacpp-presets]# ffmpeg

ffmpeg version git-2014-05-30-d136fe6 Copyright (c) 2000-2014 the FFmpeg developers

  built on Jun  2 2014 12:25:26 with gcc 4.1.2 (GCC) 20080704 (Red Hat 4.1.2-54)

  configuration: --enable-gpl --enable-nonfree --enable-libfaac --enable-libmp3lame --enable-libvorbis --enable-libvpx --enable-libx264 --enable-shared

  libavutil      52. 87.100 / 52. 87.100

  libavcodec     55. 65.100 / 55. 65.100

  libavformat    55. 42.100 / 55. 42.100

  libavdevice    55. 13.101 / 55. 13.101

  libavfilter     4.  5.100 /  4.  5.100

  libswscale      2.  6.100 /  2.  6.100

  libswresample   0. 19.100 /  0. 19.100

  libpostproc    52.  3.100 / 52.  3.100

Hyper fast Audio and Video encoder

usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}...

Use -h to get full help or, even better, run 'man ffmpeg'

I am not sure what you mean by running the cppbuild.sh scripts.  The instructions point to building ffmpeg by going to the ffmpeg site and that is what I did.  Do I need to build ffmpeg using the cppbuild.sh script or the build instructions from the ffmpeg site?  I guess I missed that in the instructions?

[Samuel Audet]

On 06/03/2014 11:06 PM, Pete Helgren wrote:
> I am not sure what you mean by running the cppbuild.sh scripts. The
> instructions point to building ffmpeg by going to the ffmpeg site and
> that is what I did. Do I need to build ffmpeg using the cppbuild.sh
> script or the build instructions from the ffmpeg site? I guess I missed
> that in the instructions?

Yes, use cppbuild.sh to build FFmpeg. That's the point of having script
files :)

Samuel

[Pete Helgren]

Sorry, man....I am losing my mind in all this compiling...:-)  Your EARLIER instruction was to run bash cppbuild.sh install ffmpeg from the javacpp-presets folder.  I missed that when I moved to the CentOS build environment and slavishly followed the build instructions from the ffmpeg site.  Sorry.  I am NOW following your additional instructions to run cppbuild.

I'll let you know how it all turns out....

Pete

[Pete Helgren]

So, when I finally understood and followed your instructions (and, it might be worthwhile to make a note on the javacpp-presets instructions that IF you need to recompile for some other distro, then run the cppbuild.sh scripts as you indicated......).  So it all compiled and built and I still get the same error.  And, just to make sure it wasn't some RH5 vs CentOS issue or something related to the environment I have setup in RH5, I ran the code on the CentOS VM and got the same error with the JVM crash:

#

# A fatal error has been detected by the Java Runtime Environment:

#

#  SIGSEGV (0xb) at pc=0x00002afe0acc935b, pid=13907, tid=47270544607552

#

# JRE version: 6.0_30-b30

# Java VM: OpenJDK 64-Bit Server VM (23.25-b01 mixed mode linux-amd64 compressed oops)

# Problematic frame:

# C  [libswresample.so.0+0x435b]  av_get_default_channel_layout+0x435b

#

FWIW I have attached the log file from the RH5 machine (which is the same as the CentOS 5 machine.

Not sure where to go next....

[Samuel Audet]

On 06/04/2014 12:08 AM, Pete Helgren wrote:
> So, when I finally understood and followed your instructions (and, it
> might be worthwhile to make a note on the javacpp-presets instructions
> that IF you need to recompile for some other distro, then run the
> cppbuild.sh scripts as you indicated......). So it all compiled and

I thought that was pretty clearly indicated as such in the README file,
but if you see a way to clarify that, by all means, that's why there's
an "Edit" button on this page:
https://github.com/bytedeco/javacpp-presets/blob/master/README.md
Thanks!

> built and I still get the same error. And, just to make sure it wasn't
> some RH5 vs CentOS issue or something related to the environment I have
> setup in RH5, I ran the code on the CentOS VM and got the same error
> with the JVM crash:
>
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGSEGV (0xb) at pc=0x00002afe0acc935b, pid=13907, tid=47270544607552
> #
> # JRE version: 6.0_30-b30
> # Java VM: OpenJDK 64-Bit Server VM (23.25-b01 mixed mode linux-amd64 compressed oops)
> # Problematic frame:
> # C [libswresample.so.0+0x435b] av_get_default_channel_layout+0x435b
> #
> FWIW I have attached the log file from the RH5 machine (which is the
> same as the CentOS 5 machine.
>
> Not sure where to go next....

Since you're using a pretty old version of GCC, it might be hitting a
bug in its optimizer that's since been fixed. You could try to disable
optimization by modifying the script to run ./configure with the
"--disable-optimizations" option. That might fix this.

Samuel

[Pete Helgren]

Thanks again.  AH!  I did read the readme! Where I went wrong was that the section at the website under the CPPBuild scripts almost immediately jumps into a discussion of the Android operating system which, since it doesn't apply, I ignored. I'll have to think about how to best describe what I did and how I accomplished it and then I'll take a stab at editing the readme....

Disabling optimizations didn't change the result (I assume you meant to change the ./configure for the ffmpeg maven build - edit the cppbuild.sh in ffmpeg folder....if I am wrong, let me know).

I'll see if I can find a newer version of gcc to use.  I don't know enough about these kind of issues to navigate this on my own but I'll see what I can do.

[Samuel Audet]

On 06/04/2014 09:42 PM, Pete Helgren wrote:
> Thanks again. AH! I did read the readme! Where I went wrong was that
> the section at the website under the CPPBuild scripts almost immediately
> jumps into a discussion of the Android operating system which, since it
> doesn't apply, I ignored. I'll have to think about how to best describe

Maybe we just need to specify "in the case of Android" somewhere? It's
really hard to figure out what phrasing everyone will understand in the
exact right way. Unless we duplicate all the text, but then we end up
with tons of sections and tl;dr excuses, ugh.

> what I did and how I accomplished it and then I'll take a stab at
> editing the readme....

Ok, thanks!

> Disabling optimizations didn't change the result (I assume you meant to
> change the ./configure for the ffmpeg maven build - edit the cppbuild.sh
> in ffmpeg folder....if I am wrong, let me know).
>
> I'll see if I can find a newer version of gcc to use. I don't know
> enough about these kind of issues to navigate this on my own but I'll
> see what I can do.

It looks like they are still testing with GCC 4.1.2 and it works fine:
http://fate.ffmpeg.org/
So the problem must be elsewhere... SEGV_ACCERR, that's interesting.
Never seen that before. Maybe it has something to do with SELinux? Or
exec-shield?
https://code.google.com/p/go/issues/detail?id=3440

Samuel

[Pete Helgren]

Still plugging away.......

Installed gcc version 4.4 and then recompiled everything.  I still get an error but I DO get some more information now:

[mp3 @ 0x1c076b00] incomplete frame

#

# A fatal error has been detected by the Java Runtime Environment:

#

#  SIGSEGV (0xb) at pc=0x00002b40379ae2bf, pid=1802, tid=47554762303808

#

# JRE version: 6.0_30-b30

# Java VM: OpenJDK 64-Bit Server VM (23.25-b01 mixed mode linux-amd64 compressed oops)

# Problematic frame:

# C  [libswresample.so.0+0x42bf]  av_get_default_channel_layout+0x42bf

#

# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again

#

# An error report file with more information is saved as:

# /root/loadtest/hs_err_pid1802.log

#

# If you would like to submit a bug report, please include

# instructions how to reproduce the bug and visit:

#   http://icedtea.classpath.org/bugzilla

# The crash happened outside the Java Virtual Machine in native code.

# See problematic frame for where to report the bug.

#

Aborted

Something is going wrong in  av_get_default_channel_layout (based on what I see here).   I disabled optimizations even with this newer compiler and it made no difference.  I'll see what I can come up with but if you have any ideas, I could sure use the help.....

[Pete Helgren]

Nothing more.  I thought I saw more information in the log but except for a small change in references I don't see anything different.  Not sure why av_get_default_channel_layout dies at this point and why there is an "[mp3 @ 0x16e1ba00] incomplete frame" message just before it dies but that is where the problem lies.  Don't know why it is dying in Linux and not Windows either.....

[Samuel Audet]

2014/06/05 1:57 "Pete Helgren" <peteh...@gmail.com>:

>
> Nothing more.  I thought I saw more information in the log but except for a small change in references I don't see anything different.  Not sure why av_get_default_channel_layout dies at this point and why there is an "[mp3 @ 0x16e1ba00] incomplete frame" message just before it dies but that is where the problem lies.  Don't know why it is dying in Linux and not Windows either.....

Maybe it's something funny with the MP3 file... If you could prepare a test case, I could try it on my machine see what happens

Samuel

[Pete Helgren]

Will do but since these are "real life" files, files uploaded by our users and processed OK by our current method which is to simply concatenate them together with no resampling, if the app is going to kill the JVM any time an unusual file comes along I'll have to come up with another solution.  There are hundreds of files that get uploaded and processed every day and I really can't be having the JVM fall over every time someone uploads a bad file.  They do that all the time now: partial files, unsupported formats, corrupted files, you name it...they upload it.

I'll put up a full test case and send you a link.

[Samuel Audet]

On 06/05/2014 09:43 PM, Pete Helgren wrote:
> Will do but since these are "real life" files, files uploaded by our
> users and processed OK by our current method which is to simply
> concatenate them together with no resampling, if the app is going to
> kill the JVM any time an unusual file comes along I'll have to come up
> with another solution. There are hundreds of files that get uploaded
> and processed every day and I really can't be having the JVM fall over
> every time someone uploads a bad file. They do that all the time now:
> partial files, unsupported formats, corrupted files, you name it...they
> upload it.

It's very unusual for FFmpeg to crash because of bad files actually.
They are testing the hell out of it, so I don't think that's the problem.

It's just that if I can reproduce here whatever is happening, then I'd
be in a better position to fix this.

> I'll put up a full test case and send you a link.

Ok, thanks! BTW, you can probably stuff that in a Gist:
https://gist.github.com/

Samuel

[Pete Helgren]

Before I do that, what version of Linux did you compile the binaries on?  I might spin up a VM and test it there first before I build a test case.  I would need to know if it is some quirk or CentOS 5 and RH5 or is a general issue.  So, if you can let me know what version of Linux you use, then I'll test it there first an then if it still fails, then I'll post up a test case for you.

FWIW at this point, the JVM falls over on every mp3 file I try to merge.  So I can take a single mp3 file, merge it to itself and when the app runs, the JVM falls over.  So right now I cannot get it to run for any mp3 file.  

[Samuel Audet]

On 06/06/2014 12:12 AM, Pete Helgren wrote:
> Before I do that, what version of Linux did you compile the binaries on?
> I might spin up a VM and test it there first before I build a test
> case. I would need to know if it is some quirk or CentOS 5 and RH5 or
> is a general issue. So, if you can let me know what version of Linux
> you use, then I'll test it there first an then if it still fails, then
> I'll post up a test case for you.

That's also in the README file: Fedora 20. But I've heard people using
the binaries on recent Ubuntu distributions with no problems.

> FWIW at this point, the JVM falls over on every mp3 file I try to merge.
> So I can take a single mp3 file, merge it to itself and when the app
> runs, the JVM falls over. So right now I cannot get it to run for any
> mp3 file.

So, it has something with do with the mp3 decoder... ?

Samuel

[Pete Helgren]

"That's also in the README file:"  SIGH...I have got to spend more time reading CAREFULLY.

I'll let you know how it goes today....

[Pete Helgren]

On Saturday, June 7, 2014 1:26:33 AM UTC-5, Samuel Audet wrote:

On 06/06/2014 12:12 AM, Pete Helgren wrote:
> Before I do that, what version of Linux did you compile the binaries on?
>   I might spin up a VM and test it there first before I build a test
> case.  I would need to know if it is some quirk or CentOS 5 and RH5 or
> is a general issue.  So, if you can let me know what version of Linux
> you use, then I'll test it there first an then if it still fails, then
> I'll post up a test case for you.

That's also in the README file: Fedora 20. But I've heard people using
the binaries on recent Ubuntu distributions with no problems.

> FWIW at this point, the JVM falls over on every mp3 file I try to merge.
>   So I can take a single mp3 file, merge it to itself and when the app
> runs, the JVM falls over.  So right now I cannot get it to run for any
> mp3 file.

So, it has something with do with the mp3 decoder... ?

So this could be a maybe....I got Fedora 20 installed and running and updated a few tools.  Then I copied over your binaries and my java jars and ran the programs.  I got an error right away:

 org.bytedeco.javacv.FrameRecorder$Exception: avcodec_find_encoder() error: Audio codec not found.

at org.bytedeco.javacv.FFmpegFrameRecorder.startUnsafe(FFmpegFrameRecorder.java:427)

At first I thought I had a class path issue but then I realized that perhaps you hadn't compiled with the same codecs as I did. So I rebuilt the libraries again: libfaac, libmp3lame, libvorbis, libvpx and then rebuilt both opencv and ffmpeg with the "bash cppbuild.sh install ffmpeg" and " bash cppbuild.sh install opencv".  They compiled OK so I ran the maven install command which also ran OK.I then copied the .jars that the maven command created in "target" to my test folder ( opencv-linux-x86_64.jar,opencv.jar,ffmpeg-linux-x86_64.jar, javacpp.jar and ffmpeg.jar)  .  Then I re-ran the java program.  This time the JVM died with a completely different error:

[pete@localhost loadtest-2]$ java -cp bsftest.jar:javacpp.jar:javacv.jar:opencv.jar:ffmpeg.jar:log4j-1.2.16.jar:ffmpeg-linux-x86_64.jar:opencv-linux-x86_64.jar  org.bsfinternational.utils.LoadTestAudioMerge /home/pete/new_tests 2 5

Beginning loadtest processing at 06/09/2014 2:43:22 PM

log4j:WARN No appenders could be found for logger (org.bsfinternational.utils.LoadTestAudioMerge).

log4j:WARN Please initialize the log4j system properly.

log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.

#

# A fatal error has been detected by the Java Runtime Environment:

#

#  SIGSEGV (0xb) at pc=0x00007f20f68f339a, pid=26141, tid=139779340580608

#

# JRE version: OpenJDK Runtime Environment (7.0_55-b13) (build 1.7.0_55-mockbuild_2014_05_22_13_12-b00)

# Java VM: OpenJDK 64-Bit Server VM (24.51-b03 mixed mode linux-amd64 compressed oops)

# Problematic frame:

# C  [ld-linux-x86-64.so.2+0x1839a]  index+0x1a

#

One step forward, two steps back.  I'll post up a Gist and and let you give it a try....

Samuel

[Pete Helgren]

The Gist was a no-go:  10mb limit.  I zipped up the files (MP3 and the jars).  The loadtest folder has the jars and the new_tests folder has the mp3's.  I used the following to to invoke the program from within the loadtest folder:

 java -cp bsftest.jar:javacpp.jar:javacv.jar:opencv.jar:ffmpeg.jar:log4j-1.2.16.jar:ffmpeg-linux-x86_64.jar:opencv-linux-x86_64.jar  org.bsfinternational.utils.LoadTestAudioMerge ../new_tests 2 5 

You need to adjust that for your folder locations but you get the drift.  I have posted the actual code that I am running earlier in this thread.  Let me know if you need anything else.  OH...you can find the files here:

http://petesworkshop.com/downloads/sigsegv.zip

[Pete Helgren]

You will probably get the JVM Crash as well but just in case you don't here is the log of the crash:

[Samuel Audet]

On 06/10/2014 06:05 AM, Pete Helgren wrote:
> The Gist was a no-go: 10mb limit. I zipped up the files (MP3 and the
> jars). The loadtest folder has the jars and the new_tests folder has
> the mp3's. I used the following to to invoke the program from within
> the loadtest folder:
>
> java -cp
> bsftest.jar:javacpp.jar:javacv.jar:opencv.jar:ffmpeg.jar:log4j-1.2.16.jar:ffmpeg-linux-x86_64.jar:opencv-linux-x86_64.jar
> org.bsfinternational.utils.LoadTestAudioMerge ../new_tests 2 5
>
> You need to adjust that for your folder locations but you get the drift.
> I have posted the actual code that I am running earlier in this
> thread. Let me know if you need anything else. OH...you can find the
> files here:
>
> http://petesworkshop.com/downloads/sigsegv.zip

Your binaries depend on "libfdk-aac.so.0" and I couldn't figure out
where you got that library, so I appended `--enable-libmp3lame` to the
`./configure` line in the `cppbuild.sh` file, and executed
$ bash cppbuild.sh install ffmpeg
$ mvn clean deploy --projects ffmpeg

With the new `ffmpeg-linux-x86_64.jar` file I got and this code on your
data:

FrameGrabber intro = new
FFmpegFrameGrabber("Fedora_20/new_tests/BSFCopyright.mp3");
FrameGrabber lecture = new
FFmpegFrameGrabber("Fedora_20/new_tests/test_2/TEMPLecture.mp3");
intro.start();
lecture.start();

FrameRecorder recorder = new FFmpegFrameRecorder("output.mp3", 1);

recorder.setSampleFormat(intro.getSampleFormat());
recorder.setSampleRate(intro.getSampleRate());
recorder.setAudioChannels(intro.getAudioChannels());
recorder.setAudioBitrate(64000);
recorder.start();

Frame frame;
while ((frame = intro.grabFrame()) != null) {
recorder.record(frame);
}

while ((frame = lecture.grabFrame()) != null) {
recorder.record(frame);
}

intro.stop();
lecture.stop();
recorder.stop();


Everything works just fine:

Input #0, mp3, from 'Fedora_20/new_tests/BSFCopyright.mp3':
Duration: 00:00:35.13, start: 0.025057, bitrate: 64 kb/s
Stream #0:0: Audio: mp3, 44100 Hz, mono, s16p, 64 kb/s
Input #0, mp3, from 'Fedora_20/new_tests/test_2/TEMPLecture.mp3':
Duration: 00:00:35.13, start: 0.025057, bitrate: 64 kb/s
Stream #0:0: Audio: mp3, 44100 Hz, mono, s16p, 64 kb/s
Output #0, mp3, to 'output.mp3':
Stream #0:0: Audio: mp3, 44100 Hz, mono, s16p, 64 kb/s


So, I don't know where the problem is, unfortunately. I uploaded the
binaries I obtained from that build here:
https://oss.sonatype.org/content/repositories/snapshots/org/bytedeco/javacpp-presets/ffmpeg/2.2.1-0.8-2-SNAPSHOT/

Samuel

[Pete Helgren]

Thanks yet again....

Well, I don't know my encoding schemes that well so I just followed the ffmpeg compile instructions for CentOS found here:  http://trac.ffmpeg.org/wiki/CompilationGuide/Centos The libfdk_aac libarary was used in that build so I just followed the same instructions when I built for Fedora 20.  I guess it is possible that the libfdk_aac is part of the problem but I think I also built using libfaac as well and got the same results.

Is libmp3lame enough to encode and decode MP3 files?  I'll try building ffmpeg with just the libmp3lame library like you have and see what happens.  Again, most of this stuff is voodoo to me: You follow the formula and a result pops out...when it comes to compiling and codecs and all the other ffmpeg stuff....what I know would fill a thimble....

I'll try your binary files and see what happens as well.  Getting it all to work in CentOS 5/RedHat 5 is the goal though.  If it works in Fedora, I hope I can determine what it is that is breaking it in CentOS/RH...

And, as I understand it, when I get openCV and ffmpeg built using javacpp-presets, the resulting .jars will contain all I need to run the code in Java, correct?  Even if I have ffmpeg installed and running at the command line, when I invoke the java program setting the classpath to use the binaries created with javacpp-presets I'll be invoke THOSE jars and binaries, regardless of the environment (correct?)

[Samuel Audet]

On 06/16/2014 04:56 AM, Pete Helgren wrote:
> Thanks yet again....
>
> Well, I don't know my encoding schemes that well so I just followed the
> ffmpeg compile instructions for CentOS found here:
> http://trac.ffmpeg.org/wiki/CompilationGuide/Centos The libfdk_aac
> libarary was used in that build so I just followed the same instructions
> when I built for Fedora 20. I guess it is possible that the libfdk_aac
> is part of the problem but I think I also built using libfaac as well
> and got the same results.
>
> Is libmp3lame enough to encode and decode MP3 files? I'll try building
> ffmpeg with just the libmp3lame library like you have and see what
> happens. Again, most of this stuff is voodoo to me: You follow the
> formula and a result pops out...when it comes to compiling and codecs
> and all the other ffmpeg stuff....what I know would fill a thimble....

libmp3lame is all we need for MP3 files yes.

> I'll try your binary files and see what happens as well. Getting it all
> to work in CentOS 5/RedHat 5 is the goal though. If it works in Fedora,
> I hope I can determine what it is that is breaking it in CentOS/RH...

We probably just need to run the same exactly two commands I gave you,
and it should work. After modifying the cppbuild.sh file.

> And, as I understand it, when I get openCV and ffmpeg built using
> javacpp-presets, the resulting .jars will contain all I need to run the
> code in Java, correct? Even if I have ffmpeg installed and running at
> the command line, when I invoke the java program setting the classpath
> to use the binaries created with javacpp-presets I'll be invoke THOSE
> jars and binaries, regardless of the environment (correct?)

Yes, that's how it should work, unless there is a bug somewhere :) but
that's the intent yes.

Samuel

[Pete Helgren]

Your binaries do work in Fedora 20 (although I got an error about a video codec error because one of the mp3's had a jpg display or something.  But it wasn't a SIGSEGV and I did get output.  I then switched back to my CentOS 6.5 distro and I am back to getting the SIGSEGV fault.

The only change I made to the javacpp-presets was to change the cppbuild.sh in ffmpeg and added the --enable-libmp3lame switch to the compile.  ldconfig -v shows this:

/usr/local/lib:

        libx264.so.142 -> libx264.so.142

        libmp3lame.so.0 -> libmp3lame.so.0.0.0

/usr/local/lib64:

        libpostproc.so.52 -> libpostproc.so.52.3.100

        libswscale.so.2 -> libswscale.so.2.5.102

        libavdevice.so.55 -> libavdevice.so.55.10.100

        libopencv_contrib.so.2.4 -> libopencv_contrib.so.2.4.9

        libopencv_imgproc.so.2.4 -> libopencv_imgproc.so.2.4.9

        libtbb.so -> libtbb.so

        libopencv_flann.so.2.4 -> libopencv_flann.so.2.4.9

        libavutil.so.52 -> libavutil.so.52.66.100

        libopencv_calib3d.so.2.4 -> libopencv_calib3d.so.2.4.9

        libopencv_highgui.so.2.4 -> libopencv_highgui.so.2.4.9

        libopencv_features2d.so.2.4 -> libopencv_features2d.so.2.4.9

        libavfilter.so.4 -> libavfilter.so.4.2.100

        libopencv_superres.so.2.4 -> libopencv_superres.so.2.4.9

        libopencv_stitching.so.2.4 -> libopencv_stitching.so.2.4.9

        libopencv_nonfree.so.2.4 -> libopencv_nonfree.so.2.4.9

        libopencv_core.so.2.4 -> libopencv_core.so.2.4.9

        libopencv_video.so.2.4 -> libopencv_video.so.2.4.9

        libopencv_photo.so.2.4 -> libopencv_photo.so.2.4.9

        libswresample.so.0 -> libswresample.so.0.18.100

        libopencv_legacy.so.2.4 -> libopencv_legacy.so.2.4.9

        libavcodec.so.55 -> libavcodec.so.55.52.102

        libopencv_videostab.so.2.4 -> libopencv_videostab.so.2.4.9

        libopencv_gpu.so.2.4 -> libopencv_gpu.so.2.4.9

        libopencv_objdetect.so.2.4 -> libopencv_objdetect.so.2.4.9

        libavformat.so.55 -> libavformat.so.55.33.100

        libopencv_ml.so.2.4 -> libopencv_ml.so.2.4.9

So again....fresh install of CentOS 6.5.  Downloaded javacpp-presets.  (I had to install CMAKE, maven and gcc-c++ and I think a couple of other tools along the way).  I then modified the cppbuild.sh script in ffmpeg and added the compile switch to include the libmp3lame library.  I then ran:

bash cppbuild.sh install ffmpeg

bash cppbuild.sh install opencv

and then 

mvn install --projects opencv, ffmpeg

I then copied the jars out or the target folder into my test folder.  When I ran the java program I got the SIGSEGV fault error.

[Samuel Audet]

On 06/17/2014 07:05 AM, Pete Helgren wrote:
> Your binaries do work in Fedora 20 (although I got an error about a
> video codec error because one of the mp3's had a jpg display or
> something. But it wasn't a SIGSEGV and I did get output. I then
> switched back to my CentOS 6.5 distro and I am back to getting the
> SIGSEGV fault.

What about if you try to build it the same exact way on Fedora 20? If
your build crashes on Fedora 20, then we'll know you are doing something
wrong. But if it doesn't crash, we'll know it's something that has to do
with CentOS.

Samuel

[Pete Helgren]

I am pretty sure it has something to do with CentOS but my Linux skills are meager and the number of switches and compile options/optimizations in Linux seems endless.

What I haven't done is replicate the steps on Fedora 20.  I just used the binaries you provided.  So, yeah, it is either a problem with the way I am compiling/building and deploying OR it is an issue with the CentOS environment.  So, I am going to start from scratch and begin with a fresh copy of Fedora and carefully document each step (e.g. what tool I downloaded and install and whatever configuration steps I perform) and I'll see if I end up with the same results.  You obviously did something I didn't on Fedora 20 because I wasn't able to get even MY program to run and you were.

So, I'll walk through the whole thing on Fedora and see what happens (and I'll document everything so you can see if I missed anything).

In reality I only need to do two things:

1) Rebuild/recompile using javacpp-presets which will produce the jars

2) Deploy those jars into my test folder with my app and run it.

The extra things that I think I end up doing are getting the development tools installed (gcc and c++ compilers and the Java SDK), getting maven installed (needed CMake, I think) and getting the codecs installed (libmp3lame is the only one at this point)

I'll let you know....

[Pete Helgren]

So here is the lengthy results of my all day effort:

Update VMWare tools:

su -c 'yum update kernel'

<no updates>

su -c 'yum install perl'

su -c 'yum install gcc'

su -c "yum install kernel-headers kernel-devel"

su -c 'yum install gcc-c++'

downloaded and extracted  the latest javacpp-presets *source* from the github website

switched to that folder

edited the cppbuild.sh script in the ffmpeg folder to add the libmp3lame codec

added the RPM Fusion repos to the Fedora distro

added the lame libraries -   

su -c 'yum install lame-libs.x86_64'

 ran  bash cppbuild.sh install ffmpeg

yasm/nasm is flagged as missing 

su -c 'yum install yasm.x86_64'

Missing x264 libraries -  

su -c 'yum install x264-libs.x86_64'

Still having issues with compile of ffmpeg in javacpp-presets (can't find libx264) so removed x264 libs

su -c 'yum remove x264.x86_64 x264-libs.x86_64'

Then pulled from git: 

git clone  git://git.videolan.org/x264

added perl-Digest-MD5 for x264 compile

had to disable open-cl in order to compile ("error: ‘x264_opencl_source’ undeclared") plus added a couple of other switches  - ./configure --enable-shared --enable-static --disable-opencl --libdir=/usr/local/lib64 --extra-ldflags="-I/usr/local/include -L/usr/local/lib64"

built ffmpeg:

su -c 'bash cppbuild.sh install ffmpeg'

built opencv:

su -c 'bash cppbuild.sh install opencv'

Had in to install Maven in order to run the mvn command:

su -c 'yum install maven'

then ran:

su -c 'mvn install --projects opencv,ffmpeg'

Then copied the jars out of the target folder into my test folder.

I get the following SIGSEGV:

#

# A fatal error has been detected by the Java Runtime Environment:

#

#  SIGSEGV (0xb) at pc=0x00007fb4626d739a, pid=13149, tid=140412449801984

#

# JRE version: OpenJDK Runtime Environment (7.0_55-b13) (build 1.7.0_55-mockbuild_2014_05_22_13_12-b00)

# Java VM: OpenJDK 64-Bit Server VM (24.51-b03 mixed mode linux-amd64 compressed oops)

# Problematic frame:

# C  [ld-linux-x86-64.so.2+0x1839a]  index+0x1a

#

# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again

#

# An error report file with more information is saved as:

# /tmp/jvm-13149/hs_error.log

#

# If you would like to submit a bug report, please include

# instructions on how to reproduce the bug and visit:

#   http://icedtea.classpath.org/bugzilla

#

Aborted (core dumped)

So I then took your binaries of ffmpeg and replaced the ones I had built.  The program runs fine!  So, I think the issue is the ffmpeg build process.  I had several issues with the x264 lib, which really shouldn't play here, correct?  So there is some other issue in the ffmpeg build from javacpp-presets that is causing the issue.  At least that caused the SIGSEGV in Fedora 20.  We haven't gotten to the same point in CentOS but if I can understand what I am doing in Fedora that is causing the SIGSEGV then I can maybe figure out what is going wrong in CentOS.

I may try a build without the x264 library and see if that helps at all.....

[Samuel Audet]

On 06/18/2014 07:03 AM, Pete Helgren wrote:
> So I then took your binaries of ffmpeg and replaced the ones I had
> built. The program runs fine! So, I think the issue is the ffmpeg
> build process. I had several issues with the x264 lib, which really
> shouldn't play here, correct? So there is some other issue in the
> ffmpeg build from javacpp-presets that is causing the issue. At least
> that caused the SIGSEGV in Fedora 20. We haven't gotten to the same
> point in CentOS but if I can understand what I am doing in Fedora that
> is causing the SIGSEGV then I can maybe figure out what is going wrong
> in CentOS.

What you say that you are doing seems alright. So, I think you may be
doing something more than what you say, which doesn't seem important to
you, but that actually is and would be the cause of the problem...

Maybe I'll start building the Linux releases under CentOS. It seems
everyone wants to run that on CentOS for some reason, but no one is
offering to make the builds :(

> I may try a build without the x264 library and see if that helps at all.....

libx264 should get built by cppbuild.sh, but yeah it has nothing to do
with MP3 so that's not the problem I'm pretty sure.

Samuel

[Pete Helgren]

Sigh...this just gets stranger.....

I decided to build ffmpeg without x264 libraries. The configure ended up looking like this in cppbuild.sh:

    linux-x86_64)

        cd $X264

        ./configure --enable-static --enable-pic

        make -j4

        cd ..

        ./configure --enable-shared --enable-gpl --enable-version3 --enable-runtime-cpudetect --disable-outdev=sdl --enable-libmp3lame  --extra-ldflags="-ldl" --libdir=/usr/local/lib64/ --shlibdir=/usr/local/lib64/

        make -j4

        sudo make install

        ;;

So, you can see the changes I made (I know next to nothing on compiling...)...I pretty much removed this:

 --enable-libx264 --extra-cflags="-I$X264" --extra-ldflags="-L$X264" 

from the configure.  Then I built ffmpeg again using:

bash cppbuild.sh install ffmpeg

and then the maven stuff

mvn install --projects ffmpeg

Then I copied the ffmpeg.jar and the ffmpeg-linux-x86_64.jar over to my test folder, replacing my jars.  It worked!  I have no idea why....removing the references to x264 makes no sense....

I went back to my CentOS 5 VM and repeated the same steps...essentially rebuilding both ffmpeg and opencv and then running the mvn command and copying the jars over to the test folder.  It failed with a SIGSEGV (same one) error.  

So, I created a clean CentOS 5 VM and repeated the process.  Right now I am stuck on the 'bash cppbuild.sh install opencv' step.  I get a compiler failure at the tbb step:

/root/javacpp-presets/opencv/cppbuild/opencv-2.4.9/build_linux-x86_64/3rdparty/tbb/tbb41_20130116oss/include/tbb/tbb_config.h:255:6: error: #error "GCC atomic built-ins are not supported."

Not sure how to get past that.  Googling on the error in tbb yields nothing but references to the header file.  I am running CentOS 5 and gcc version 4.1.2 20080704 (Red Hat 4.1.2-54) and cmake version 2.8.10.2

(don't know if any of that makes a difference.

I am going to take a look at my CentOS 6 VM next and see if I can make any progress there.  But, getting this to work on CentOS 5.3 is the goal.....

Just a question here:

I run the bash cppbuild.sh install ffmpeg and the bash cppbuild.sh install opencv which appears to compile the projects but when I run the 'mvn install --projects opencv,ffmpeg' step it seems like it is compiling yet again.  So the question is: what to the cppbuild do and what does mvn do?

[Pete Helgren]

Sorry to repeatedly post....

CentOS 6 also still has the SIGSEGV fault after removing references to the libx264 libraries so I really don't know why the Fedora 20 re-build of opencv and ffmpeg (without x264) fixed it.  It WAS a different SIGSEGV in Fedora 20 so maybe I am chasing my tail on this.  At this point, I am not sure what the next step is except to see if you could build on CentOS 5.3 (or 6.3 for that matter).

Sorry, I really wanted to help out with building for those distros for you....

[Samuel Audet]

On 06/19/2014 05:10 AM, Pete Helgren wrote:
> /root/javacpp-presets/opencv/cppbuild/opencv-2.4.9/build_linux-x86_64/3rdparty/tbb/tbb41_20130116oss/include/tbb/tbb_config.h:255:6:
> error: #error "GCC atomic built-ins are not supported."

You can remove the reference to TBB from the cmake config like of
OpenCV, you won't need that.

Samuel

[Samuel Audet]

On 06/19/2014 05:10 AM, Pete Helgren wrote:

> I run the bash cppbuild.sh install ffmpeg and the bash cppbuild.sh
> install opencv which appears to compile the projects but when I run the
> 'mvn install --projects opencv,ffmpeg' step it seems like it is
> compiling yet again. So the question is: what to the cppbuild do and
> what does mvn do?

I'll just paraphrase the README file here, but the idea is that this is
split in such a way that the scripts are not actually needed: "Each
child module in turn relies on its corresponding native library being
installed in the directory specified". As long as the native library is
installed on the system, that's all we need.

So, Maven is "To rebuild the source code on the Java side" (and that
includes such things as JNI which is a C/C++ API for Java), and
cppbuild.sh scripts are "To build native libraries on the native C/C++
side". That's about it. Maven wasn't made for C/C++ libraries, so it
doesn't work by itself, while CMake and friends were not made for Java
(or JNI), so we need something else there, which Maven can take of,
through JavaCPP anyway. But eventually I'd like "Replacing the
Bash/Maven build combo by something better (Gradle?)"

That said, I'm not sure what kind of answer you're looking for here...
Can you elaborate?

Samuel

[Samuel Audet]

Let's see what Jason comes up with

Samuel

[Pete Helgren]

Not sure why, having read the readme, I am missing so much essential information.  Perhaps I'll propose a readme format that is a little clearer.  My goal is to understand what, exactly, is going on so that I can understand (perhaps) what I am doing wrong.

So, to paraphrase your paraphrase:

1) The cppbuild creates the C++ binaries

2) The Maven tool packages up those binaries for use in jars by javacv.

So what I am seeing is that when my app runs, javacv is unpacking the libs into a /tmp/javacpp<timestamp?> folder and using those shared objects in the JNI calls? Correct?  My app dies when the swresample library initializes.  Specifically it dies at initialization:

public static native int swr_init(SwrContext s); // from the ffmpeg JNI source generated by javacpp

The SIGSEGV doesn't say exactly what the fault is that occurs in the C code, but my wild guess is that the context object is null and that causes the SIGSEGV.  I wonder of it has something to do with running it in the /tmp folder ? (don't know, I really don't know linux).  I DO see differences between the contents of the /tmp/javacpp* folder in Fedora 20 vs CentOS 5.  In the Fedora 20 installation, the /tmp/javacpp* folders have three shared object libraries: 

-rw-rw-r--. 1 pete pete 8474000 Jun 17 16:15 libavcodec.so.55

-rw-rw-r--. 1 pete pete  273216 Jun 17 16:15 libavutil.so.52

-rw-rw-r--. 1 pete pete  556504 Jun 17 16:15 libjniavcodec.so

in the new CentOS 5 build (my orginal 5.3 )  I see many more libraries listed, including the offending libswresample.

-rw-r--r--. 1 root root 9995360 Jun 18 16:52 libavcodec.so.55

-rw-r--r--. 1 root root   48728 Jun 18 16:52 libavdevice.so.55

-rw-r--r--. 1 root root 1111376 Jun 18 16:52 libavfilter.so.4

-rw-r--r--. 1 root root 1608944 Jun 18 16:52 libavformat.so.55

-rw-r--r--. 1 root root  262544 Jun 18 16:52 libavutil.so.52

-rw-r--r--. 1 root root  601928 Jun 18 16:52 libjniavcodec.so

-rw-r--r--. 1 root root   48864 Jun 18 16:52 libjniavdevice.so

-rw-r--r--. 1 root root  477016 Jun 18 16:52 libjniavformat.so

-rw-r--r--. 1 root root  480352 Jun 18 16:52 libjniavutil.so

-rw-r--r--. 1 root root   44424 Jun 18 16:52 libjniswresample.so

-rw-r--r--. 1 root root  310720 Jun 18 16:52 libpostproc.so.52

-rw-r--r--. 1 root root   99416 Jun 18 16:52 libswresample.so.0

-rw-r--r--. 1 root root  453984 Jun 18 16:52 libswscale.so.2

Ownership id different but the read/write/execute attributes are nearly the same.  Looks like the root group only has read access (no big deal I think).

Interesting to see that difference.  Not sure of it is significant.

[Samuel Audet]

On 06/19/2014 09:54 PM, Pete Helgren wrote:
> Not sure why, having read the readme, I am missing so much essential
> information. Perhaps I'll propose a readme format that is a little
> clearer. My goal is to understand what, exactly, is going on so that I
> can understand (perhaps) what I am doing wrong.

Did you make sure to --disable-optimizations ? Since you got it working
in Fedora 20 now, it might be a bug in the old compiler somewhere that's
causing the remaining crash..

Samuel

[Pete Helgren]

Set that switch where?

[Samuel Audet]

On 06/19/2014 10:38 PM, Pete Helgren wrote:
> Did you make sure to --disable-optimizations ? Since you got it working
> in Fedora 20 now, it might be a bug in the old compiler somewhere
> that's causing the remaining crash..
>
> Set that switch where?
>

On the line after the ./configure in the cppbuild.sh script

[Pete Helgren]

OK.  Thanks...I managed to get everything to compile in the new CentOS 5.3 VM yesterday.  I used a newer GCC (4.4) (had to because of an issue compiling freak.cpp) but I get the SIGSEGV in the same place.  I set up Eclipse on that distro and ran debug.  It doesn't appear that JNI is the issue with the SIGSEGV, although I am not completely sure.  I added breakpoints in FFmpegFrameRecorder where a call to av_get_default_channel_layout is made and the JVM never crashed.  It crashes later so there must be a call to it somewhere else.  I am trying to get the debug environment set up so I can debug the JNI calls but I am really pushing the edges of my knowledge and skill set.  I have learned all this stuff on my own so I have large gaps in my understanding about how it all works.

I'll try disabling optimization and I am going to recompile libswresample with debugging enabled and see where I end up.  I'd love to figure out what the issue is and get it taken care of......

[Pete Helgren]

WOW! That did it!  Disabling the optimizations seems to have fixed the issue.  This is on the "clean" CentOS 5 install I did yesterday so next I'll move the jars over to the Red Hat 5 server I am using to test on (since it is a clone of production) and I'll let you know....

[Pete Helgren]

Even better, it works on the RH el5 distro as well!  So, I am moving forward again!

I'll see if I can build a complete RH/CentOS 5 set of binaries at some point soon.  Right now I only compiled in the libmp3lame support for ffmpeg.  

Thanks for your patience over the past 3 weeks.  I have learned much and will try to provide some documentation and binaries to help the project overall.

Pete

[Samuel Audet]

On 06/20/2014 10:59 PM, Pete Helgren wrote:
> WOW! That did it! Disabling the optimizations seems to have fixed the
> issue. This is on the "clean" CentOS 5 install I did yesterday so next
> I'll move the jars over to the Red Hat 5 server I am using to test on
> (since it is a clone of production) and I'll let you know....

Great, thanks for letting us know :)

Now, let's see if CentOS 7 comes with a good enough version of GCC, and
if it does, let's start making release builds for Linux on that as it
comes with YASM 1.2, at least.

Samuel

[Samuel Audet]

On 06/21/2014 12:16 AM, Pete Helgren wrote:
> Even better, it works on the RH el5 distro as well! So, I am moving
> forward again!
>
> I'll see if I can build a complete RH/CentOS 5 set of binaries at some
> point soon. Right now I only compiled in the libmp3lame support for
> ffmpeg.
>
> Thanks for your patience over the past 3 weeks. I have learned much and
> will try to provide some documentation and binaries to help the project
> overall.

Thanks! More documentation is always welcome :)

BTW, I've noticed recently that it might be possible to create our own
CI servers for free with this service:
https://travis-ci.org/
If it's something that you or anyone else would like to work on...

Samuel