Regression in mp3 audio stream handling

[fritsch]

Summary of the bug:
ffplay produces a whole lot of
[mp3 @ 0x7f024000a7a0] Header missingB vq= 6678KB sq= 0B f=0/0 Last message repeated 47 times
[mp3 @ 0x7f024000a7a0] Header missingB vq= 6714KB sq= 0B f=0/0 Last message repeated 2 times
[mp3 @ 0x7f024000a7a0] Header missingB vq= 6709KB sq= 0B f=0/0 Last message repeated 43 times
[mp3 @ 0x7f024000a7a0] Header missingB vq= 6717KB sq= 0B f=0/0 Last message repeated 26 times

and audio is stuttering and frequently dropped / skipped.

This worked fine with ffmpeg 2.7.3.

You can download the sample here: ​http://fritsch.fruehberger.net/ffmpeg/denis-mp3-broken.mp4

[Carl Eugen Hoyos]

For future tickets: Please always provide your failing command line together with the complete, uncut console output, only test with ffplay if an issue is not reproducible with ffmpeg.

Regression since ae215e2b / 6ec688e1 - related to ticket #4938.

$ ffmpeg -i denis-mp3-broken_cut.mp4 -t 10 -qscale 2 out.avi
ffmpeg version N-76950-ga814f1d Copyright (c) 2000-2015 the FFmpeg developers
  built with gcc 4.7 (SUSE Linux)
  configuration:
  libavutil      55.  9.100 / 55.  9.100
  libavcodec     57. 16.101 / 57. 16.101
  libavformat    57. 19.100 / 57. 19.100
  libavdevice    57.  0.100 / 57.  0.100
  libavfilter     6. 17.100 /  6. 17.100
  libswscale      4.  0.100 /  4.  0.100
  libswresample   2.  0.101 /  2.  0.101
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'denis-mp3-broken_cut.mp4':
  Metadata:
    major_brand     : mp42
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : HandBrake 0.10.0 2014112200
  Duration: 00:11:08.02, start: 0.080000, bitrate: 30 kb/s
    Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, smpte170m/bt470bg/bt709), 704x576 [SAR 16:11 DAR 16:9], 780 kb/s, 25 fps, 25 tbr, 90k tbn, 180k tbc (default)
    Metadata:
      handler_name    : VideoHandler
    Stream #0:1(und): Audio: mp3 (mp4a / 0x6134706D), 48000 Hz, stereo, s16p, 122 kb/s (default)
    Metadata:
      handler_name    : Stereo
Please use -q:a or -q:v, -qscale is ambiguous
Output #0, avi, to 'out.avi':
  Metadata:
    major_brand     : mp42
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    ISFT            : Lavf57.19.100
    Stream #0:0(und): Video: mpeg4 (FMP4 / 0x34504D46), yuv420p, 704x576 [SAR 16:11 DAR 16:9], q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc (default)
    Metadata:
      handler_name    : VideoHandler
      encoder         : Lavc57.16.101 mpeg4
    Stream #0:1(und): Audio: ac3 ([0] [0][0] / 0x2000), 48000 Hz, stereo, fltp, 192 kb/s (default)
    Metadata:
      handler_name    : Stereo
      encoder         : Lavc57.16.101 ac3
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> mpeg4 (native))
  Stream #0:1 -> #0:1 (mp3 (native) -> ac3 (native))
Press [q] to stop, [?] for help
[mp3 @ 0x25d45e0] Header missing
Error while decoding stream #0:1: Invalid data found when processing input
[mp3 @ 0x25d45e0] Header missing
Error while decoding stream #0:1: Invalid data found when processing input                    

...

...

[mp3 @ 0x25d45e0] Header missing
Error while decoding stream #0:1: Invalid data found when processing input
[mp3 @ 0x25d45e0] Header missing
Error while decoding stream #0:1: Invalid data found when processing input
frame=  250 fps=0.0 q=2.0 Lsize=    5736kB time=00:00:10.00 bitrate=4698.8kbits/s
video:5706kB audio:8kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.386214%

[fritsch]

fritsch@t440s:~/Desktop/FFmpeg$ git bisect bad
6ec688e1bc76dd93151cbca1c340162ae4b10d77 is the first bad commit
commit 6ec688e1bc76dd93151cbca1c340162ae4b10d77
Author: nu774 <​honeycomb77@gmail.com>
Date: Fri May 9 23:05:42 2014 +0900

mp3: enable packed main_data decoding in MP4

14496-3 suggests packing main_data of MP3 that is usually scattered
into multiple frames due to bit reservoir.

However, after packing main_data into a access unit, bitrate index
in the MPEG audio frame header doesn't match with actual frame size.

In order to accept this, this patch removes unnecessary frame size
checking on mp3 decoder.

Also, mov demuxer was changed to use MP3 parser only on special cases
(QT MOV with specific sample description) to avoid re-packetizing.

Signed-off-by: Luca Barbato <​lu_zero@gentoo.org>

:040000 040000 857f53268fa5c5a994fe27c3b3beb91cae3e5320 43810c8e18abbccb618dd9057837de4d7a8e1fe3 M libavcodec
:040000 040000 2f6dfb3868f684ca94a575da5ef89176d1fd20e8 37eefdc905b277f7efd727a4529d8276840b970d M libavformat
:040000 040000 eac8ef6d85c3818ebec2d8c573a99eaa9c234ce4 f9f33d9633a9d44873f7842b2a1eadd84d1714e4 M tests

[Carl Eugen Hoyos]

Replying to fritsch:

fritsch@t440s:~/Desktop/FFmpeg$ git bisect bad
6ec688e1bc76dd93151cbca1c340162ae4b10d77 is the first bad commit

See comment:1 for this information

[fritsch]

I read comment:1 and will do this for future tickets.

Did you also mean for "future replies to this ticket"?

[fritsch]

Okay - got it. Sorry for the noise. Btw. for the future - if you could write a bit more clearly on what the next step could be - then people like me with the ability to bisect and understand code could help you in a better way without doubling your work.

Reverting the named commit and fixing the hunks makes the mp3 work on latest master.

Do you want me to send a patch? Or do you already have one in the queue? Please also consider 2.8 branch - as we will ship kodi v16 2.8.x based.

[Carl Eugen Hoyos]

Replying to fritsch:

Okay - got it. Sorry for the noise. Btw. for the future - if you could write a bit more clearly on what the next step could be - then people like me with the ability to bisect and understand code could help you in a better way without doubling your work.

Sorry, I don't understand: I asked for things that you should do when reporting future tickets, I added all information that I considered useful for this ticket, ie both the relevant version hashes for the regression and a link to a related ticket and the missing console output. Additionally I set the status of this ticket to "open - reproduced" meaning that no further information is required. I did not ask for a next step because there was no obvious next step. Note that all discussion related to fixing issues are meant to happen on the FFmpeg development mailing list, not on this bug tracker.

Reverting the named commit and fixing the hunks makes the mp3 work on latest master.

Thank you for confirming that my regression tests were correct.

Do you want me to send a patch?

If you can improve the existing heuristic please send a patch.

Or do you already have one in the queue?

A patch was discussed but it breaks other files:
​http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/204316

[fritsch]

Thanks for the link. Your colleagues on IRC showed me that sample, too.

To be honest: I did not find a single player in linux world that could play this dropbox linked sample (mplayer, totem, mpg123, ffplay 2.7.3, vlc) nothing but ffplay-master :-)

But all of them (minus ffplay-master) played the sample reported in this issue here.

[Michael Niedermayer]

Fixed in 861f47ddf463926da2cba9e12665e7f004419f4b