[Libav-user] Problems decoding mp3 files

Carl Eugen Hoyos cehoyos at ag.or.at
Mon Apr 28 14:34:11 CEST 2014


b.mcdonagh at ... <b.mcdonagh at ...> writes:

> I have just tried calling ffmpeg version from cmd 
> line in the bin folder of ffmpeg build to no avail. 

to no avail?
You mean nothing happened?

> ./configure --prefix=/mingw/ffmpegbuild 

> --disable-stripping --enable-debug=3

This is probably good for debugging but didn't you 
say before that you don't know how to debug?

> --extra-cflags="-gstabs+"

Is this a good idea?
(It absolutely may be, I am curious if it made a 
difference for you.)

> --enable-extra-warnings 

Why?

> --enable-cross-compile 
> --cross-prefix=arm-unknown-nto-qnx8.0.0eabi- 
> --arch=armv7 target-os=qnx 

> --disable-asm

Generally, this is a very, very bad idea.
It is very valuable for debugging though.
(I just want to make sure that you only 
enabled it for improved debugging.)

> --enable-memalign-hack

Is this necessary?
If it is not necessary, I believe it is 
better to remove this option.

> --enable-gpl 

> --disable-optimizations

Same as "--disable-asm"

> --disable-static --enable-shared
> --enable-libx264 --enable-pthreads 
> --extra-cflags=-I/mingw/include/myinclude/x264includes/
> --extra-ldflags=-L/mingw/lib/mylib/lib/ && make && 

> make install

I wonder if make install makes much sense for 
cross-compiling but this is unrelated.

> Do you have a reference of any kind to learn how to 
> successfully run fate on your target hardware.

Is there also a native compiler for your device?
If not, it is not trivial but assuming you want to 
actually use the compiled software (commercially?) 
and none of our tests run on qnx, I would strongly 
suggest that you do the effort.
Start with installing a ssh certificate that allows 
login without password and produce a shared directory 
(ie either a directory on your device that you can 
access from your compilation host or a directory on 
your compilation host that is mounted on your device).

sshfs is not recommended since it apparently does not 
support a minimal locking that is required to run the 
fate test suite (the host runs the ffmpeg command on 
the device using ssh, when the command returns, the 
host accesses the output file which unfortunately was 
not written yet by the ffmpeg command on the device. 
(Tested on two osx laptops.)
This does not happen with smb.

Running fate with a native compiler is trivial:
$ ./configure ...
$ make SAMPLES=fate-suite fate-rsync
$ make SAMPLES=fate-suite fate

Carl Eugen



More information about the Libav-user mailing list