Why decoding AAC with ffmpeg doesn't work...

Update: The workaround for the problem doesn't work for ffmpeg versions more recent than 20.06.2011 as libfaad support was dropped in favour of the now stable native ffmpeg AAC encoder! If you still have a separate compilation of libfaad you can workaround using the "faad" encoder tool as described in this post.

If you are using recent ffmpeg versions to decode a .MOV file you might get the following error:

Stream #0.0(eng): Audio: aac, 48000 Hz, 2 channels, s16
Stream #0.1(eng): Video: h264, yuv420p, 1280x530, PAR 1:1 DAR 128:53, 25 tbr, 25 tbn, 50 tbc
Output #0, flv, to 'test.flv':
Stream #0.0(eng): Video: flv (hq), yuv420p, 400x164 [PAR 101:102 DAR 050:2091], 
q=2-31, 300 kb/s, 1k tbn, 25 tbc
Stream #0.1(eng): Audio: libmp3lame, 22050 Hz, 2 channels, s16, 64 kb/s
Stream mapping:
Stream #0.1 -> #0.0
Stream #0.0 -> #0.1
Press [q] to stop encoding
[aac @ 0x80727a0]channel element 1.0 is not allocated
Error while decoding stream #0.0
Error while decoding stream #0.0
Error while decoding stream #0.0
Error while decoding stream #0.0
Error while decoding stream #0.0
Error while decoding stream #0.0

The message "Error while decoding stream #0.0" is repeated continuously. The resulting video is either unplayable or has no sound. Still the input video is playable in all standard players (VLC, in Windows...). The reason for the problem as I understood it is that the ffmpeg-builtin AAC codec cannot handle an audio stream stream with index "1.0". This is documented in various bugs (see ffmpeg issues #800, #871, #999, #1733...). It doesn't look like this will be handled by ffmpeg very soon. In fact it could well be that they'll handle it as an invalid input file.

Solution: Upgrade to latest ffmpeg and faad library version and add " -acodec libfaad " in front of the "-i" switch. This uses the libfaad AAC decoder, which is said to be a bit slower than the ffmpeg-builtin, but which decodes the AAC without complaining. For example:

ffmpeg -acodec libfaad -i input.mov -b 300kbit/s -ar 22050 -o test.flv

The "-acodec" preceding the "-i" option only influences the input audio decoding, not the audio encoding.

rsync: buffer_append_space: alloc 10512504 not supported

If an rsync call gives you the following:

buffer_append_space: alloc 10512504 not supported
rsync: writefd_unbuffered failed to write 4092 bytes [sender]: Broken pipe (32)
rsync: connection unexpectedly closed (36 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(635) [sender=3.0.3]

Don't bother to debug rsync! This is an SSH problem. You need to upgrade your SSH version (which is propably some 4.3 or older).

Reasons for ffmpeg "av_interleaved_write_frame(): I/O error occurred"

If you are unlucky you might see the following ffmpeg error message:
Output #0, image2, to 'output.ppm':
Stream #0.0: Video: ppm, rgb24, 144x108, q=2-31, 200 kb/s, 90k tbn, 29.97 tbc
Stream mapping:
Stream #0.0 -> #0.0
Press [q] to stop encoding
av_interleaved_write_frame(): I/O error occurred
Usually that means that input file is truncated and/or corrupted.

The above error message was produced with a command like this
ffmpeg -v 0 -y -i 'input.flv' -ss 00:00:01 -vframes 1 -an -sameq -vcodec ppm -s 140x100 'output.ppm'

There are several possible reasons for the error message "av_interleaved_write_frame(): I/O error occurred".

  1. You are extracting a thumb and forgot to specify to extract a single frame only (-vframes 1)
  2. You have a broken input file.
  3. And finally: The target file cannot be written.

The above was caused by problem three. After a lot of trying I found that the target directory did not exist. Quite confusing.

How to Quickly Set up Squid

Ever needed to test your HTTP client app proxy support? Need an instant proxy test setup?

Here is a fast way to set up a local proxy server on Debian using squid:

1.) # apt-get install squid
2.) Edit the squid configuration /etc/squid/squid.conf
2.) a) Edit ACLs. Ensure to have something like the following:

acl all src all
acl users proxy_auth REQUIRED

2.) b) Edit access definitions. You need (order is important):

http_access allow users
http_access deny all

2.) c) Setup a dummy authentication module

auth_param basic program /usr/local/bin/squid_dummy_auth
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive off

3.) Create a authentication script

# vi /usr/local/bin/squid_dummy_auth

Insert something like:


while read dummy;
   echo OK

# chmod a+x /usr/local/bin/squid_dummy_auth

4.) Restart squid

# /etc/init.d/squid restart

With this you have a working Basic Auth proxy test setup running on localhost:3128.

1000 Problems When Compiling ffmpeg and mplayer

This is a short compilation of ffmpeg/mplayer compilation pitfalls:

If compilation fails with an error about the numbers of parameters in common/cpu.c
you need to check which glibc version is used. Remove the second parameter to
sched_getaffinity() if necessary and recompile.

ffmpeg configure fails with:

ERROR: libx264 not found
If you think configure made a mistake, make sure you are using the latest
version from SVN.  If the latest version fails, report the problem to the
[email protected] mailing list or IRC #ffmpeg on irc.freenode.net.
Include the log file "config.err" produced by configure as this will help
solving the problem.

This can be caused by two effects:

  • Unintended library is used for linking. Check wether you have different ones installed. Avoid this and uninstall them if possible. If necessary use LD_LIBRARY_PATH or --extra-ldflags to change the search order.
  • Incompatible combination of ffmpeg and libx264. Older libx264 provide a method x264_encoder_open which older ffmpeg versions do check for. More recent libx264 add a version number to the method name. Now when you compile a new libx264 against an older ffmpeg the libx264 detection that relies on the symbol name fails. As a workaround you could hack the configure script to check for "x264_encoder_open_78" instead of "x264_encoder_open" (given that 78 is the libx264 version you use).

ffmpeg compilation fails on AMD64 with:

libavcodec/svq3.c: In function 'svq3_decode_slice_header':
libavcodec/svq3.c:721: warning: cast discards qualifiers from pointer target type
libavcodec/svq3.c:724: warning: cast discards qualifiers from pointer target type
libavcodec/svq3.c: In function 'svq3_decode_init':
libavcodec/svq3.c:870: warning: dereferencing type-punned pointer will break strict-aliasing rules
/tmp/ccSySbTo.s: Assembler messages:
/tmp/ccSySbTo.s:10644: Error: suffix or operands invalid for `add'
/tmp/ccSySbTo.s:10656: Error: suffix or operands invalid for `add'
/tmp/ccSySbTo.s:12294: Error: suffix or operands invalid for `add'
/tmp/ccSySbTo.s:12306: Error: suffix or operands invalid for `add'
make: *** [libavcodec/h264.o] Error 1

This post explains that this is related to a glibc issue and how to patch it.

ffmpeg compilation fails with:

libavcodec/libx264.c: In function 'encode_nals':
libavcodec/libx264.c:60: warning: implicit declaration of function 'x264_nal_encode'
libavcodec/libx264.c: In function 'X264_init':
libavcodec/libx264.c:169: error: 'x264_param_t' has no member named 'b_bframe_pyramid'
make: *** [libavcodec/libx264.o] Error 1

This means you are using incompatible ffmpeg and libx264 versions. Try to upgrade ffmpeg or to downgrade libx264.


/usr/include/linux/videodev.h:55: error: syntax error before "ulong"
/usr/include/linux/videodev.h:71: error: syntax error before '}' token


--- configure.ac.080605 2005-06-08 21:56:04.000000000 +1200
+++ configure.ac        2005-06-08 21:56:42.000000000 +1200
@@ -1226,6 +1226,7 @@
 [#ifdef HAVE_SYS_TIME_H
 #include <sys/time.h>
+#include <sys/types.h>
 #include <asm/types.h>


oder Workaround:
--disable-demuxer=v4l --disable-muxer=v4l --disable-demuxer=v4l2 --disable-muxer=v4l2

ffmpeg+old make

make: *** No rule to make target `libavdevice/libavdevice.so', needed by `all'.  Stop.

Problem: GNU make is too old, you need at least v3.81

http://www.mail-archive.com/[email protected]/msg01284.html

make: *** No rule to make target `install-libs', needed by `install'.  Stop.

Problem: GNU make is too old, you need at least v3.81


Mplayer+old make

make: expand.c:489: allocated_variable_append: Assertion `current_variable_set_list->next != 0' failed.

Problem: GNU make is too old, you need at least v3.81


i386/dsputil_mmx.o i386/dsputil_mmx.c
i386/dsputil_mmx.c: In function `transpose4x4':
i386/dsputil_mmx.c:621: error: can't find a register in class `GENERAL_REGS' while reloading `asm'

Workaround: Add the following to your configure call
--extra-cflags="-O3 -fomit-frame-pointer"

Note: if this somehow helped you and you know something to be added feel free to post a comment!

Debugging the OpenEMM Bounce Handling Setup

The following is a short summary of things to configure to get OpenEMM bounce handling to work. The problem is mostly setting up the connection from your sendmail setup, through the milter plugin provided by OpenEMM which then communicates with another daemon "bavd" which as I understand it keeps per mail address statistics and writes the bounce results into the DB.

The things that can be the cause for problems are these:

  1. Your sendmail setup.
  2. The bav* python scripts not working.
  3. The bavd daemon not running/working.
  4. DB access not working
  5. Missing bounce filter in OpenEMM.
  6. Missing bounce alias in bav config.

The real good thing is that OpenEMM is so very well documented that you just need to lookup the simple how to documentation and everything will work within 5min... Sorry just kidding! They seem to want to make money on books and support and somehow don't write documentation and rely on endless forum posts of clueless users.

Enough of a rant below you find some hints how to workaround the problem causes I mentioned above:

Setup Preconditions:

  1. Within OpenEMM a bounce filter has to be configured. Name and description do not matter, it just needs to exist.
  2. The sendmail setup must have milter running the OpenEMM "bav" filter. So /etc/mail/sendmail.mc should have a line like
    INPUT_MAIL_FILTER(`bav', `S=unix:/var/run/bav.sock, F=T')dnl
  3. The sendmail log (e.g. /var/log/mail.log) must be readable by your OpenEMM user


  1. Define mail alias matching the bounce filter: Edit your bav.conf-local (e.g.
    /etc/openemm/conf/bav/bav.conf-local) and add something like
    [email protected] alias:[email protected]

    with "ext_6" being the sender address and ext_12 the bounce filter address.

Check List:

  1. Ensure the "bavd" daemon is running (its log file can be found in /var/log/*-<host>-bavd.log)
    • Ensure bavd server port 5166 is open
    • Ensure mails are passed to bavd (look for "scanMessage" lines in log file)
    • Ensure both soft and hard bounces are found (DSN 4.x.x and DSN 5.x.x)
  2. Ensure the bav filter is running. Check "ps -ef" output for "bav -L INFO"
  3. Ensure bounces are set your OpenEMM DB instance:
    select count(*) from customer_1_binding_tbl where user_status=2;

    The meaning of the user_status value is as following:

    Value Meaning
    1 active
    2 hard bounce
    3 opt out by admin
    4 opt out by user

    (see OpenEMM Handbuch)

    Also remember that hard bounces might not be generated immediately. In case of soft bounces OpenEMM waits for up to 7 bounces to consider the mail address as bounced.

Cfagent Refuses to Run on New Client

Sometimes Cfengine refuse to run on a new client and simply does not explain what the problem is. The error message (which you only see when running cfagent with -v) looks like this:

cfengine:client:/var/opt/dsau/cfengine/inputs/update.conf:194: Warning:
actionsequence is empty
cfengine:client:/var/opt/dsau/cfengine/inputs/update.conf:194: Warning: perhaps
cfagent.conf/update.conf have not yet been set up? 

The message "actionsecquence is empty" really means that the cfagent.conf is empty, because it could not be retrieved. The question then is why couldn't it be retrieved. Here is a check list:

  1. update.conf is somehow broken
  2. Master host cannot be contacted in network
  3. Master host and client believe the hostname to be a different IP

In my case the problem was caused by the #3 due to different /etc/hosts the hostname did not resolve into the same IP as on the cfengine master.

Usability of cfengine sucks...

Syndicate content Syndicate content