MP3 parser get frame_size wrong

[adam_csheng]

Summary of the bug:
MP3 parser get the frame_size wrong when playback,
the second and third frame_size are wrong.
How to reproduce:

ffprobe -show_packets $FILENAME[[BR]]
The first packet is right, packet size is 488
[PACKET]
codec_type=audio
stream_index=0
pts=0
pts_time=0.000000
dts=0
dts_time=0.000000
duration=384
duration_time=0.008707
convergence_duration=N/A
convergence_duration_time=N/A
size=488
pos=167471
flags=K
[/PACKET]
The second packet size is wrong: 333
[PACKET]
codec_type=audio
stream_index=0
pts=383
pts_time=0.008685
dts=383
dts_time=0.008685
duration=384
duration_time=0.008707
convergence_duration=N/A
convergence_duration_time=N/A
size=333
pos=167959
flags=K
[/PACKET]
And the third packets is wrong:643
[PACKET]
codec_type=audio
stream_index=0
pts=767
pts_time=0.017392
dts=767
dts_time=0.017392
duration=384
duration_time=0.008707
convergence_duration=N/A
convergence_duration_time=N/A
size=643
pos=N/A
flags=K
[/PACKET]
The fourth packets is right:488
[PACKET]
codec_type=audio
stream_index=0
pts=1151
pts_time=0.026100
dts=1151
dts_time=0.026100
duration=384
duration_time=0.008707
convergence_duration=N/A
convergence_duration_time=N/A
size=488
pos=168935
flags=K
[/PACKET]

Analysis:
As the first packet get the pc->state is 0xFFFFE275.
When parser the second packet, the first four bytes is 0xFFFFE205,
then get the state is 0xFFE205FF when only use the first second packet byte 0xFF
by state= (state<<8) + buf[i++];
Then get the wrong MP3 header for this file but it's a valid MP3 frame header.

[Carl Eugen Hoyos]

Is this also reproducible with ffmpeg (the application)? If yes, please provide complete, uncut console output.

[adam_csheng]

It's a parser issue, so it should be reproduced by ffmpeg.
What do you want to get from ffmpeg, and what command should I use?

[Carl Eugen Hoyos]

If you try the following command line, is there any audible distortion in the output file?
If yes, please post command line together with complete, uncut console output to make this a valid ticket.
$ ffmpeg -i M4A_MP1_288Kbps_CBR_44.1KHz_2ch.m4a out.wav

[adam_csheng]

ffmpeg version N-44159-g3b6e9cd Copyright (c) 2000-2012 the FFmpeg developers

built on Sep 5 2012 10:28:08 with gcc 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5)
configuration: --disable-yasm
libavutil 51. 70.100 / 51. 70.100
libavcodec 54. 55.100 / 54. 55.100
libavformat 54. 25.104 / 54. 25.104
libavdevice 54. 2.100 / 54. 2.100
libavfilter 3. 15.103 / 3. 15.103
libswscale 2. 1.101 / 2. 1.101
libswresample 0. 15.100 / 0. 15.100

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '../stream/M4A_MP1_288Kbps_CBR_44.1KHz_2ch_complete.m4a':

Metadata:

major_brand : isom
minor_version : 0
compatible_brands: mp41
creation_time : 2010-06-23 03:38:42
encoder : vlc 1.0.3 stream output
encoder-eng : vlc 1.0.3 stream output

Duration: 00:03:30.99, start: 0.000000, bitrate: 454 kb/s

Stream #0:0(eng): Audio: mp1 (mp4a / 0x6134706D), 44100 Hz, stereo, s16, 448 kb/s
Metadata:

creation_time : 2010-06-23 03:38:42
handler_name : SoundHandler

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

Metadata:

major_brand : isom
minor_version : 0
compatible_brands: mp41
encoder-eng : vlc 1.0.3 stream output
encoder : Lavf54.25.104
Stream #0:0(eng): Audio: pcm_s16le ([1][0][0][0] / 0x0001), 44100 Hz, stereo, s16, 1411 kb/s
Metadata:

creation_time : 2010-06-23 03:38:42
handler_name : SoundHandler

Stream mapping:

Stream #0:0 -> #0:0 (mp1 -> pcm_s16le)

Press [q] to stop, ? for help
[mp1 @ 0x2302d80] incomplete frame
Error while decoding stream #0:0: Invalid data found when processing input
[mp1 @ 0x2302d80] Header missing
Error while decoding stream #0:0: Invalid data found when processing input
size= 36345kB time=00:03:30.99 bitrate=1411.1kbits/s
video:0kB audio:36345kB subtitle:0 global headers:0kB muxing overhead 0.000124%

[adam_csheng]

Above is the console output.
Although there isn't any audible distortion, the second and third packet are decoding error.
Is this should be a invalid bug?
Thanks

[adam_csheng]

Have you ever seen my analysis about this issue?
And if I add one line code 'state = 0;' after 'uint32_t state= pc->state;' line 48 in mpegaudio_parser.c,
the issue would be gone.
But I think you may give some formal patch for this issue.
Thanks

[Carl Eugen Hoyos]

Replying to adam_csheng:

Have you ever seen my analysis about this issue?

If you know how to fix this problem, please send a patch to ffmpeg-devel.
(You can also attach the patch here, but patches generally receive more attention on the mailing list.)

[adam_csheng]

I've sent patch to ffmpeg-devel.