First audio packet is always corrupted when parsing PCM

[Marcel Poelstra]

Summary of the bug:

The following issue came up while investigating a suspected issue with hls streams, where always the first AAC audio packet in the first segment seemed to be filled with garbage.
During investigation we also discovered that the exact symptoms varied with the different codec options (like libfdk or native ffmpeg aac).
While searching for the best codec (with the less amount of artifacts), it appeared that the generated garbage was actually created while parsing the source PCM audio. It looks like the aac artifacts in the first packet we saw initially, were just caused by this.
In short: copying a pcm source file through ffmpeg causes damage to the first audio packet of 1024 samples in the outputfile.
Once this output is being encoded into e.g. aac, the effect is even more apparent.

Attached screenshots of our analyzer tool show some examples of the issues mentioned.

How to reproduce:

% ffmpeg -i  testin.wav  -c:a copy  testout.wav
ffmpeg version git-master
built on Jan.5th 2016

Best regards
Marcel Poelstra
SBS Broadcasting, The Netherlands

[Marcel Poelstra]

Analyzer screenshot 440kHz test tone pcm codec copy

[Marcel Poelstra]

Analyzer screenshot 440kHz test tone aac encoded with Fraunhofer

[Marcel Poelstra]

Analyzer screenshot 440kHz test tone aac encoded with native ffmpeg aac codec

[Marcel Poelstra]

Analyzer screenshot 440kHz test tone source file (untouched)

[Carl Eugen Hoyos]

Please provide the command line that exhibits the issue you are describing together with the complete, uncut console output to make this a valid ticket and please provide your input sample.

[Marcel Poelstra]

Commandline is already in the ticket, but just to be sure, it can be reproduced by copy-encoding any wav file by 'ffmpeg -i testin.wav -c:a copy testout.wav'

In case of the aac codecs this would be : 'ffmpeg -i testin.wav -c:a libfdk-aac testout.aac' or 'ffmpeg -i testin.wav -c:a aac testout.aac

Attached are the input en output wav's of our test.

[Marcel Poelstra]

PCM source file with test tone (zipped)

[Marcel Poelstra]

PCM codec copied file with test tone (zipped)

[Marcel Poelstra]

console output :

[root@beheer-marcel2 testnieuwjaar2]# ffmpeg -i 440Hz_44100Hz_16bit_30sec.wav -c:a copy  testout.wav
ffmpeg version N-43433-g68eb208 Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 4.8.5 (GCC) 20150623 (Red Hat 4.8.5-4)
  configuration: --prefix=/root/ffmpeg_build --extra-cflags=-I/root/ffmpeg_build/include --extra-ldflags=-L/root/ffmpeg_build/lib --bindir=/root/bin --pkg-config-flags=--static --enable-gpl --enable-nonfree --enable-libfdk-aac --enable-libfreetype --enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265
  libavutil      55. 12.100 / 55. 12.100
  libavcodec     57. 21.100 / 57. 21.100
  libavformat    57. 21.100 / 57. 21.100
  libavdevice    57.  0.100 / 57.  0.100
  libavfilter     6. 23.100 /  6. 23.100
  libswscale      4.  0.100 /  4.  0.100
  libswresample   2.  0.101 /  2.  0.101
  libpostproc    54.  0.100 / 54.  0.100
Guessed Channel Layout for  Input Stream #0.0 : mono
Input #0, wav, from '440Hz_44100Hz_16bit_30sec.wav':
  Metadata:
    date            :
    artist          :
    title           :
    genre           :
    comment         :
    IENG            :
    copyright       :
    encoder         :
  Duration: 00:00:30.00, bitrate: 706 kb/s
    Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 44100 Hz, 1 channels, s16, 705 kb/s
Output #0, wav, to 'testout.wav':
  Metadata:
    ICRD            :
    IART            :
    INAM            :
    IGNR            :
    ICMT            :
    IENG            :
    ICOP            :
    ISFT            : Lavf57.21.100
    Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 44100 Hz, mono, 705 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
Press [q] to stop, [?] for help
size=    2584kB time=00:00:30.00 bitrate= 705.6kbits/s speed=1.5e+03x
video:0kB audio:2584kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.002948%

[Carl Eugen Hoyos]

The input file and the output file contain identical audio data, just look at the files with a hexeditor after cutting the beginning of the file until the "data" tag.

Why do you believe the output file is different?

00000000  52 49 46 46 ac 6d 28 00  57 41 56 45 66 6d 74 20  |RIFF.m(.WAVEfmt |
00000010  10 00 00 00 01 00 01 00  44 ac 00 00 88 58 01 00  |........D....X..|
00000020  02 00 10 00 64 61 74 61  f0 5f 28 00 00 00 8c 05  |....data._(.....|
00000030  13 0b 8e 10 fa 15 4e 1b  87 20 a0 25 92 2a 5a 2f  |......N.. .%.*Z/|
00000040  f2 33 57 38 81 3c 71 40  1e 44 87 47 a9 4a 7e 4d  |.3W8.<q@.D.G.J~M|
00000050  07 50 3f 52 23 54 b3 55  ee 56 d1 57 5b 58 8d 58  |.P?R#T.U.V.W[X.X|
00000060  66 58 e5 57 0c 57 db 55  55 54 7a 52 4b 50 cc 4d  |fX.W.W.UUTzRKP.M|
00000070  ff 4a e6 47 85 44 de 40  f7 3c d3 38 75 34 e3 2f  |.J.G.D.@.<.8u4./|
00000080  20 2b 31 26 1d 21 e7 1b  95 16 2c 11 b2 0b 2e 06  | +1&.!....,.....|
00000090  a1 00 15 fb 8d f5 10 f0  a3 ea 4c e5 10 e0 f3 da  |..........L.....|
000000a0  fc d5 2f d1 91 cc 27 c8  f5 c3 ff bf 4a bc d9 b8  |../...'.....J...|
000000b0  af b5 d0 b2 3f b0 fd ad  10 ac 75 aa 31 a9 44 a8  |....?.....u.1.D.|
000000c0  b0 a7 74 a7 91 a7 08 a8  d6 a8 fd a9 7a ab 4c ad  |..t.........z.L.|
000000d0  71 af e7 b1 ab b4 bd b7  15 bb b4 be 94 c2 b2 c6  |q...............|
000000e0  0a cb 96 cf 54 d4 3e d9  4e de 80 e3 cf e8 36 ee  |....T.>.N.....6.|
000000f0  ad f3 32 f9 be fe 49 04  d2 09 50 0f c0 14 1a 1a  |..2...I...P.....|

00000000  52 49 46 46 36 60 28 00  57 41 56 45 66 6d 74 20  |RIFF6`(.WAVEfmt |
00000010  10 00 00 00 01 00 01 00  44 ac 00 00 88 58 01 00  |........D....X..|
00000020  02 00 10 00 4c 49 53 54  1a 00 00 00 49 4e 46 4f  |....LIST....INFO|
00000030  49 53 46 54 0e 00 00 00  4c 61 76 66 35 37 2e 32  |ISFT....Lavf57.2|
00000040  31 2e 31 30 30 00 64 61  74 61 f0 5f 28 00 00 00  |1.100.data._(...|
00000050  8c 05 13 0b 8e 10 fa 15  4e 1b 87 20 a0 25 92 2a  |........N.. .%.*|
00000060  5a 2f f2 33 57 38 81 3c  71 40 1e 44 87 47 a9 4a  |Z/.3W8.<q@.D.G.J|
00000070  7e 4d 07 50 3f 52 23 54  b3 55 ee 56 d1 57 5b 58  |~M.P?R#T.U.V.W[X|
00000080  8d 58 66 58 e5 57 0c 57  db 55 55 54 7a 52 4b 50  |.XfX.W.W.UUTzRKP|
00000090  cc 4d ff 4a e6 47 85 44  de 40 f7 3c d3 38 75 34  |.M.J.G.D.@.<.8u4|
000000a0  e3 2f 20 2b 31 26 1d 21  e7 1b 95 16 2c 11 b2 0b  |./ +1&.!....,...|
000000b0  2e 06 a1 00 15 fb 8d f5  10 f0 a3 ea 4c e5 10 e0  |............L...|
000000c0  f3 da fc d5 2f d1 91 cc  27 c8 f5 c3 ff bf 4a bc  |..../...'.....J.|
000000d0  d9 b8 af b5 d0 b2 3f b0  fd ad 10 ac 75 aa 31 a9  |......?.....u.1.|
000000e0  44 a8 b0 a7 74 a7 91 a7  08 a8 d6 a8 fd a9 7a ab  |D...t.........z.|
000000f0  4c ad 71 af e7 b1 ab b4  bd b7 15 bb b4 be 94 c2  |L.q.............|

[Carl Eugen Hoyos]

Replying to marcel_poelstra:

[root@beheer-marcel2 testnieuwjaar2]# ffmpeg

I know this is unrelated but please allow me to emphasize that this is always a very, very bad idea: Afaik, there can be no reason that makes it necessary to run ffmpeg as root and it typically has a high risk potential.

[Marcel Poelstra]

Replying to cehoyos:
No really ? wow.... /sarcastic_mode_off

FYI this is just a VM I used for testing, so no worries, I know what I'm doing.....

Replying to marcel_poelstra:

[root@beheer-marcel2 testnieuwjaar2]# ffmpeg

I know this is unrelated but please allow me to emphasize that this is always a very, very bad idea: Afaik, there can be no reason that makes it necessary to run ffmpeg as root and it typically has a high risk potential.

[Marcel Poelstra]

Replying to cehoyos:

Of course the payload is the same.... that is not the issue. Please have a look at the screenshots I sent from the analyzer. Not only the payload, but the container should be OK as well !

The input file and the output file contain identical audio data, just look at the files with a hexeditor after cutting the beginning of the file until the "data" tag.

Why do you believe the output file is different?

00000000  52 49 46 46 ac 6d 28 00  57 41 56 45 66 6d 74 20  |RIFF.m(.WAVEfmt |
00000010  10 00 00 00 01 00 01 00  44 ac 00 00 88 58 01 00  |........D....X..|
00000020  02 00 10 00 64 61 74 61  f0 5f 28 00 00 00 8c 05  |....data._(.....|
00000030  13 0b 8e 10 fa 15 4e 1b  87 20 a0 25 92 2a 5a 2f  |......N.. .%.*Z/|
00000040  f2 33 57 38 81 3c 71 40  1e 44 87 47 a9 4a 7e 4d  |.3W8.<q@.D.G.J~M|
00000050  07 50 3f 52 23 54 b3 55  ee 56 d1 57 5b 58 8d 58  |.P?R#T.U.V.W[X.X|
00000060  66 58 e5 57 0c 57 db 55  55 54 7a 52 4b 50 cc 4d  |fX.W.W.UUTzRKP.M|
00000070  ff 4a e6 47 85 44 de 40  f7 3c d3 38 75 34 e3 2f  |.J.G.D.@.<.8u4./|
00000080  20 2b 31 26 1d 21 e7 1b  95 16 2c 11 b2 0b 2e 06  | +1&.!....,.....|
00000090  a1 00 15 fb 8d f5 10 f0  a3 ea 4c e5 10 e0 f3 da  |..........L.....|
000000a0  fc d5 2f d1 91 cc 27 c8  f5 c3 ff bf 4a bc d9 b8  |../...'.....J...|
000000b0  af b5 d0 b2 3f b0 fd ad  10 ac 75 aa 31 a9 44 a8  |....?.....u.1.D.|
000000c0  b0 a7 74 a7 91 a7 08 a8  d6 a8 fd a9 7a ab 4c ad  |..t.........z.L.|
000000d0  71 af e7 b1 ab b4 bd b7  15 bb b4 be 94 c2 b2 c6  |q...............|
000000e0  0a cb 96 cf 54 d4 3e d9  4e de 80 e3 cf e8 36 ee  |....T.>.N.....6.|
000000f0  ad f3 32 f9 be fe 49 04  d2 09 50 0f c0 14 1a 1a  |..2...I...P.....|

00000000  52 49 46 46 36 60 28 00  57 41 56 45 66 6d 74 20  |RIFF6`(.WAVEfmt |
00000010  10 00 00 00 01 00 01 00  44 ac 00 00 88 58 01 00  |........D....X..|
00000020  02 00 10 00 4c 49 53 54  1a 00 00 00 49 4e 46 4f  |....LIST....INFO|
00000030  49 53 46 54 0e 00 00 00  4c 61 76 66 35 37 2e 32  |ISFT....Lavf57.2|
00000040  31 2e 31 30 30 00 64 61  74 61 f0 5f 28 00 00 00  |1.100.data._(...|
00000050  8c 05 13 0b 8e 10 fa 15  4e 1b 87 20 a0 25 92 2a  |........N.. .%.*|
00000060  5a 2f f2 33 57 38 81 3c  71 40 1e 44 87 47 a9 4a  |Z/.3W8.<q@.D.G.J|
00000070  7e 4d 07 50 3f 52 23 54  b3 55 ee 56 d1 57 5b 58  |~M.P?R#T.U.V.W[X|
00000080  8d 58 66 58 e5 57 0c 57  db 55 55 54 7a 52 4b 50  |.XfX.W.W.UUTzRKP|
00000090  cc 4d ff 4a e6 47 85 44  de 40 f7 3c d3 38 75 34  |.M.J.G.D.@.<.8u4|
000000a0  e3 2f 20 2b 31 26 1d 21  e7 1b 95 16 2c 11 b2 0b  |./ +1&.!....,...|
000000b0  2e 06 a1 00 15 fb 8d f5  10 f0 a3 ea 4c e5 10 e0  |............L...|
000000c0  f3 da fc d5 2f d1 91 cc  27 c8 f5 c3 ff bf 4a bc  |..../...'.....J.|
000000d0  d9 b8 af b5 d0 b2 3f b0  fd ad 10 ac 75 aa 31 a9  |......?.....u.1.|
000000e0  44 a8 b0 a7 74 a7 91 a7  08 a8 d6 a8 fd a9 7a ab  |D...t.........z.|
000000f0  4c ad 71 af e7 b1 ab b4  bd b7 15 bb b4 be 94 c2  |L.q.............|

[Hendrik]

The container contains metadata that doesn't necessarily have to be identical. Such metadata is not forwarded to the aac encoder, so it has no influence on its operation.

What makes you believe any differences in the container would cause audio problems?
The relevant parts of the container are identical (the "fmt" tag), and the payload is also identical (anything following "data"), so what exactly do you think is broken in the first audio frame?

[Hendrik]

Note that AAC encoders often produce "preroll" data thats supposed to not be played, but just decoded to "prime" the decoder.

[Marcel Poelstra]

I know about the preroll data. In the libfdk this is most apparent since it just adds an empty packet. In that case the problem I'm talking about is in the second packet. This is clearly visible in the screenshots I provided.
Furthermore, when I encode the same source wav with different tools, the "garbage" packet (so not the mentioned 'preroll' but really the packet with random data) is not there in all cases.
It just happens with ffmpeg. So one might conclude that something (like a pcm parser component) is effecting the source PCM to cause this.

The reason I'm putting this up is, that we run in to files on our VOD platform that simply refuse to play. Common factor is, they all contain this garbage in the first or, in case of libfdk, the second packet. So the actual payload might be perfect, but still the decoder refuses to play. Files that do not have these garbage packets always play fine.

Replying to heleppkes:

Note that AAC encoders often produce "preroll" data thats supposed to not be played, but just decoded to "prime" the decoder.

[Carl Eugen Hoyos]

Replying to marcel_poelstra:

Of course the payload is the same.... that is not the issue. Please have a look at the screenshots I sent from the analyzer.

I don't think an audio analyzer can test anything but the payload.

Not only the payload, but the container should be OK as well !

To the best of my knowledge the wav container of the file you uploaded is ok.

Please do not top-post here.

[Marcel Poelstra]

Reopening, since no solution is provided. Perhaps someone is willing to take a more closer look and spend some more time on what is really going on here....

[Carl Eugen Hoyos]

You have reported that remuxing PCM corrupts the first audio packet. This is not correct. If you have another issue consider opening another ticket or even better ask on the user mailing list.