MOC doesn't play MP3/MP4 files after upgrading to ffmpeg 1.1.2 (Unsupported sample size!, ffmpeg planar samples)

Submitted by gamezelda on Fri, 2013-02-15 18:33

Forums:

Operating system: Arch Linux (with testing repository enabled)
MOC version: 2.5.0-beta1 r2522 (but also happens with the older version in the official repositories)
Where did I get MOC from: Source code (but also happens with the older version in the official repositories)

Logs:

This is the relevant part of the server log:

Feb 15 17:07:28.211640: audio.c:421 play_thread(): Entering playing thread
Feb 15 17:07:28.211665: audio.c:439 play_thread(): Playing item 0: XXX.mp3
Feb 15 17:07:28.211699: server.c:257 wake_up_server(): Waking up the server
Feb 15 17:07:28.211726: server.c:1724 server_loop(): Got 'wake up'
Feb 15 17:07:28.211748: server.c:646 send_events(): Flushing events for client 0
Feb 15 17:07:28.211776: out_buf.c:345 out_buf_reset(): resetting the buffer
Feb 15 17:07:28.211796: player.c:357 precache_wait(): Precache thread is not running
Feb 15 17:07:28.211814: server.c:257 wake_up_server(): Waking up the server
Feb 15 17:07:28.211970: server.c:1724 server_loop(): Got 'wake up'
Feb 15 17:07:28.212053: server.c:646 send_events(): Flushing events for client 0
Feb 15 17:07:28.255901: ffmpeg.c:143 ffmpeg_log_repeats(): FFmpeg said: max_analyze_duration 5000000 reached at 5015510
Feb 15 17:07:28.256147: ffmpeg.c:143 ffmpeg_log_repeats(): FFmpeg said: Estimating duration from bitrate, this may be inaccurate
Feb 15 17:07:28.256225: ffmpeg.c:712 ffmpeg_open(): FFmpeg thinks 'XXX.mp3' is format(codec) 'mp3(mp3)'
Feb 15 17:07:28.256706: server.c:257 wake_up_server(): Waking up the server
Feb 15 17:07:28.256769: server.c:1724 server_loop(): Got 'wake up'
Feb 15 17:07:28.256794: server.c:646 send_events(): Flushing events for client 0
Feb 15 17:07:28.257324: server.c:776 server_error(): ERROR: Unsupported sample size!

This is a variable dump before the error in ffmpeg_init():

fmt_from_codec returns 0
fmt_from_sample_fmt returns 0
codec->id is 86017 = AV_CODEC_ID_MP3
data->enc->sample_fmt is 6 = AV_SAMPLE_FMT_S16P, ///< signed 16 bits, planar

Problem description:

Previously MP3 (and MP4) files worked. I had ffmpeg 1.0.1 installed, and MOC didn't load the ffmpeg plugin (I think it's because it requires version >=1?), so the other MP3 plugin was used and everything worked.

Recently ffmpeg 1.1.2 has became available in the Arch Linux testing repository. After I did the upgrade, MOC loads the ffmpeg plugin correctly and attempts to load MP3 files through ffmpeg, which doesn't work with the error "Unsupported sample size!".

MP3 files play correctly in the command line ffplay tool.

Problem analysis:

As I posted above, ffmpeg is returning a planar sample format (AV_SAMPLE_FMT_S16P) which isn't included in the enumeration on fmt_from_sample_fmt, so the sample format isn't recognized. If the sample format is added to the enumeration, then the audio plays, but it's glitchy.

This is because decode_packet has an if statement to handle planar formats, but it doesn't seem to work correctly (it doesn't seem do the interleaving well). I hacked a workaround to interleave the data in the planes and the MP3s play correctly thereafter.

jcf

Fri, 2013-02-15 19:08

Firstly, thank you for such a comprehensive bug report.

Your analysis of the bug is correct and is the same as the one identified here. I have spent the last three days testing the patch I mentioned and identified a couple of related problems along the way. Hopefully I will be committing the patch in the next day or so.

The problem is that although FFmpeg had some planar support for some time, it is only in release 1.1 that it started using it. The MOC code to handle planar was modelled on an example from a previous FFmpeg release and the FFmpeg folk seem to have changed their minds on how to do it in the interim. (Either that or the original example was buggy.) It now conforms to the way I would have expected it to work in the first place.

jcf

Tue, 2013-02-19 03:20

I have today committed r2524 which fixes this problem.

If you wish to cherrypick this patch then you should get the whole patchset r2523:2526 which will fix the related problems as well.

And the original example in FFmpeg was (and still is) buggy. You can hear this for yourself if you undefine HAVE_AVCODEC_DECODE_AUDIO4 in config.h after running configure and before running make.

dodger

Thu, 2013-02-21 08:56

It also work for me.
Thanks a lot for this wonderful player :-)

jcf

Thu, 2013-02-21 09:32

It's good to know it works for someone other than me, and that you find MOC useful.

violazoli

Thu, 2013-12-26 00:27

Hi, excuse me, I develop my own "distro" based on LFS, but I have the above error with the moc-2.5.0-beta1 ! And I searched the needed patch, but not find. Maybe I am stupid, okay. Please help me, and write a download link or to this patch, or to a new bugfixed release of the Moc source code! (beta2 version... ? ) Thanks!

jcf

Thu, 2013-12-26 05:53

The patch for this problem was committed after 2.5.0-beta1 was released, so if that's the version of MOC you are on you will still be experiencing it.

The patchsets for version 2.5.0-beta2 are complete and now in testing, but they've run into the disruption of the holiday season. We're expecting to release it before the end of January so if you can wait for that to happen then I'd recommend you do so.

If you can't wait, then your next best alternative is the current SVN HEAD. It has quite a few bug fixes over beta1 and will be more stable.

However, you may have a policy on using only released versions plus selected patches then you can cherrypick the r2523:2526 patchset from SVN (as described in the SVN diff subcommand documentation).