Screen capture WITH audio in ffmpeg

Question

I am using ffmpeg built from source at this revision in Fedora 20.

I am able to record audio perfectly fine with the command:

FFmpeg/ffmpeg -f alsa -ac 2 -i pulse -- output.wav

However, when I try both screen capture and audio, like this:

FFmpeg/ffmpeg -video_size 800x600 -framerate 25 -ac 2 -f x11grab -i :0.0+0,0 -ac 2 -f alsa -i pulse -ac 2 -acodec copy output.mpeg -ac 2

I'm getting a video with 0 audio channels, which I can check running FFmpeg/ffplay output.mpeg

Input #0, mpeg, from 'output.mpeg':
  Duration: 00:00:09.44, start: 0.540000, bitrate: 2743 kb/s
    Stream #0:0[0x1e0]: Video: mpeg1video, yuv420p(tv), 800x600 [SAR 1:1 DAR 4:3], 104857 kb/s, 25 fps, 25 tbr, 90k tbn, 25 tbc
    Stream #0:1[0x1c0]: Audio: mp2, 0 channels, s16p
   7.26 M-V:  0.000 fd=   0 aq=    0KB vq=   33KB sq=    0B f=0/0   

and no audible sound is played. The position of -ac 2 doesn't change the behaviour, nor does repeating it only once. This is despite ffmpeg claims to record the audio with 2 channels, here is the input:

ffmpeg version N-71312-ga66dcfe Copyright (c) 2000-2015 the FFmpeg developers
  built with gcc 4.8.3 (GCC) 20140911 (Red Hat 4.8.3-7)
  configuration: 
  libavutil      54. 22.100 / 54. 22.100
  libavcodec     56. 34.100 / 56. 34.100
  libavformat    56. 29.100 / 56. 29.100
  libavdevice    56.  4.100 / 56.  4.100
  libavfilter     5. 13.101 /  5. 13.101
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  1.100 /  1.  1.100
Trailing options were found on the commandline.
Input #0, x11grab, from ':0.0+0,0':
  Duration: N/A, start: 1428348285.201679, bitrate: N/A
    Stream #0:0: Video: rawvideo (BGR[0] / 0x524742), bgr0, 800x600, 25 fps, 25 tbr, 1000k tbn, 25 tbc
Guessed Channel Layout for  Input Stream #1.0 : stereo
Input #1, alsa, from 'pulse':
  Duration: N/A, start: 1428348285.225901, bitrate: 1536 kb/s
    Stream #1:0: Audio: pcm_s16le, 48000 Hz, 2 channels, s16, 1536 kb/s
 File 'output.mpeg' already exists. Overwrite ? [y/N] y
[mpeg @ 0x2d079a0] VBV buffer size not set, using default size of 130KB
If you want the mpeg file to be compliant to some specification
Like DVD, VCD or others, make sure you set the correct buffer size
Output #0, mpeg, to 'output.mpeg':
  Metadata:
    encoder         : Lavf56.29.100
    Stream #0:0: Video: mpeg1video, yuv420p, 800x600, q=2-31, 200     kb/s, 25 fps, 90k tbn, 25 tbc
    Metadata:
      encoder         : Lavc56.34.100 mpeg1video
    Stream #0:1: Audio: pcm_s16le, 48000 Hz, stereo, 1536 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> mpeg1video (native))
  Stream #1:0 -> #0:1 (copy)

I'm clueless. If anybody can tell me how to get this to work by either:

• fixing my mistakes in the command line flags
• if it's a regression, which revision to build from.
• any other way

I'll buy him/her a pint.

Answer 1

The solution seems to be to use both a different video and audio encoder. This line works:

FFmpeg/ffmpeg -video_size 1024x768 -framerate 25 -f x11grab -i :0.0+0,0 -f alsa -ac 2 -i pulse -acodec aac -strict experimental output.flv

I couldn't get it to work without -acodec aac -strict experimental, contrary to the HOWTO on ffmpeg wiki.

The error message I'm getting is:

Output #0, flv, to 'output.flv':
    Stream #0:0: Video: flv1 (flv), yuv420p, 1024x768, q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc
    Metadata:
      encoder         : Lavc56.34.100 flv
    Stream #0:1: Audio: adpcm_swf, 0 channels
    Metadata:
      encoder         : Lavc56.34.100 adpcm_swf
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> flv1 (flv))
  Stream #1:0 -> #0:1 (pcm_s16le (native) -> adpcm_swf (native))
Error while opening encoder for output stream #0:1 - maybe incorrect parameters such as bit_rate, rate, width or height

Neither could I get this to work using:

FFmpeg/ffmpeg -video_size 1024x768 -framerate 25 -f x11grab -i :0.0+0,0 -f alsa -ac 2 -i pulse -acodec copy output.mpeg

which contains -ac 2 probably in the right place. The error I'm getting repeatedly is:

[mp2 @ 0x7faffc007da0] Header missing

This most likely is a bug/regression.

To sum up, I've (probably) found 1 bug in ffmpeg and 1 bug in ffmpeg's wiki. And it looks like I'll have to buy the promised beer to myself ;)