[FFmpeg-devel] [patch] 6 channel raw audio input results in invalid PCM packet error

[Phil Rutschman]

Raw audio input fails with SVN- r15760 when the number of channels times
the number of bytes per sample isn't an integer divisor of 1024.

 

Example:

$ ffmpeg -ac 6 -ar 48000 -f s16le -i /dev/zero -t 10 silence.wav

FFmpeg version SVN-r15760, Copyright (c) 2000-2008 Fabrice Bellard, et
al.

  configuration: --enable-postproc --enable-libfaac --enable-libx264
--enable-pt

hreads --enable-pthreads --enable-gpl --enable-libfaad
--extra-libs=-L/usr/local

/lib --enable-libmp3lame

  libavutil     49.12. 0 / 49.12. 0

  libavcodec    52. 1. 0 / 52. 1. 0

  libavformat   52.23. 1 / 52.23. 1

  libavdevice   52. 1. 0 / 52. 1. 0

  libpostproc   51. 2. 0 / 51. 2. 0

  built on Oct 31 2008 11:11:46, gcc: 4.1.2 20071124 (Red Hat 4.1.2-42)

Input #0, s16le, from '/dev/zero':

  Duration: N/A, start: 0.000000, bitrate: N/A

    Stream #0.0: Audio: pcm_s16le, 48000 Hz, 5:1, s16, 4608 kb/s

Output #0, wav, to 'silence.wav':

    Stream #0.0: Audio: pcm_s16le, 48000 Hz, 5:1, s16, 4608 kb/s

Stream mapping:

  Stream #0.0 -> #0.0

Press [q] to stop encoding

[pcm_s16le @ 0xa53b410]invalid PCM packet

Error while decoding stream #0.0

[pcm_s16le @ 0xa53b410]invalid PCM packet

Error while decoding stream #0.0

[pcm_s16le @ 0xa53b410]invalid PCM packet

Error while decoding stream #0.0 

(repeats)

 

 

The problem seems to be that raw_read_audio_packet in libavformat/raw.c
always uses a 1024-byte packet size (RAW_PACKET_SIZE), but
pcm_decode_frame in libavcodec/pcm.c expects a whole number of audio
frames in the packet. With 6 input channels of 16 bit samples this is 12
bytes, which doesn't divide evenly into 1024.

 

I took a first stab at a patch to raw_read_audio_packet which peeks
inside the AVFormatContext to get the number of channels and bytes per
sample from the codec structure and adjusts the packet size to be an
integer multiple of bytes*channels. It fixes the problem for me, but I'm
not at all familiar with the code base so I don't know if this is a
legitimate operation or the best way to fix this. Feedback on a better
approach would be welcome.

 

 

 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: raw_audio_6_channels.diff
Type: application/octet-stream
Size: 719 bytes
Desc: raw_audio_6_channels.diff
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081031/dc12eb07/attachment.obj>