Opened 13 months ago

Closed 4 months ago

#7331 closed defect (invalid)

malformed input not playable in libfdk_aacdec

Reported by: ramcq Owned by:
Priority: normal Component: avcodec
Version: git-master Keywords: libfdk-aac
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Summary of the bug:

The attached .m4a file (sourced from youtube-dl -g "http://www.youtube.com/watch?v=reeQ3Nsjti0") does not play in ffplay using the libfdk_aacdec decoder in ffplay. However, GStreamer using libfdk-aac is able to play the same file without error.

How to reproduce:

% ramcq@upsilon:~$ ffplay sample.m4a 
ffplay version 3.2.10-1~deb9u1endless1beos3.4.1 Copyright (c) 2003-2018 the FFmpeg developers
  built with gcc 6.3.0 (Debian 6.3.0-18+deb9u1endless1bem1) 20170516
  configuration: --prefix=/usr --extra-version='1~deb9u1endless1beos3.4.1' --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --enable-gpl --enable-nonfree --disable-stripping --disable-doc --disable-everything --disable-ffserver --enable-encoder='ac3,mp2' --enable-decoder='pcm_s16be,pcm_s24be,pcm_mulaw,pcm_alaw' --enable-decoder='pcm_u8,pcm_s16le,pcm_s24le,pcm_f32le' --enable-decoder='theora,vorbis,vp8,vp9,mp2,mp3,ac3,libfdk_aac' --enable-parser='opus,vp3,vorbis,vp8,mpegaudio,aac,ac3' --enable-demuxer='ogg,matroska,wav,mp3,aac,ac3,m4a' --enable-protocol=file --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libcaca --enable-libcdio --enable-libfdk-aac --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmp3lame --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libzvbi --enable-openal --enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libiec61883 --enable-frei0r --enable-libopencv --enable-shared
  WARNING: library configuration mismatch
  avcodec     configuration: --prefix=/usr --extra-version='1~deb9u1endless1beos3.4.1' --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --enable-gpl --enable-nonfree --disable-stripping --disable-doc --disable-everything --disable-ffserver --enable-encoder='ac3,mp2' --enable-decoder='pcm_s16be,pcm_s24be,pcm_mulaw,pcm_alaw' --enable-decoder='pcm_u8,pcm_s16le,pcm_s24le,pcm_f32le' --enable-decoder='theora,vorbis,vp8,vp9,mp2,mp3,ac3,libfdk_aac' --enable-parser='opus,vp3,vorbis,vp8,mpegaudio,aac,ac3' --enable-demuxer='ogg,matroska,wav,mp3,aac,ac3,m4a' --enable-protocol=file --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libcaca --enable-libcdio --enable-libfdk-aac --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmp3lame --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libzvbi --enable-openal --enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libiec61883 --enable-frei0r --enable-libopencv --enable-shared --disable-doc --disable-programs --enable-decoder='h264,h263,mpeg4' --enable-hwaccel='h264_vaapi,h264_vdpau' --enable-parser='h264,mpeg4video' --enable-demuxer='h264,mov,m4v'
  libavutil      55. 34.101 / 55. 34.101
  libavcodec     57. 64.101 / 57. 64.101
  libavformat    57. 56.101 / 57. 56.101
  libavdevice    57.  1.100 / 57.  1.100
  libavfilter     6. 65.100 /  6. 65.100
  libavresample   3.  1.  0 /  3.  1.  0
  libswscale      4.  2.100 /  4.  2.100
  libswresample   2.  3.100 /  2.  3.100
  libpostproc    54.  1.100 / 54.  1.100
sample.m4a: Invalid data found when processing input
    nan    :  0.000 fd=   0 aq=    0KB vq=    0KB sq=    0B f=0/0   

Given the file is clearly slightly corrupted, I believe the difference between GStreamer and libavcodec's handling of fdk-aac is whether AAC_DEC_TRANSPORT_SYNC_ERROR is considered fatal or not. GStreamer handles it as can be seen here https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/ext/fdkaac/gstfdkaacdec.c#n214 whereas FFmpeg does not, per https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libfdk-aacdec.c#L332. The documented correct handling of AAC_DEC_TRANSPORT_SYNC_ERROR is to continue inputting buffers to the decoder, per https://github.com/esrlabs/fdk-aac/blob/master/libAACdec/include/aacdecoder_lib.h#L362.

This is also reproducible in a much newer version of ffmpeg embedded into the Chromium browser (which we have patched to use libfdk-aac) but the problem is reproducible outside of the Chromium media pipeline.

Attachments (2)

sample.m4a (1.9 MB) - added by ramcq 13 months ago.
malformed AAC audio file
endless-fdk-aac-handle-transport-sync-error.patch (1.4 KB) - added by ramcq 13 months ago.
untested patch (my build environment is broken atm)

Download all attachments as: .zip

Change History (16)

Changed 13 months ago by ramcq

malformed AAC audio file

Changed 13 months ago by ramcq

untested patch (my build environment is broken atm)

comment:1 Changed 13 months ago by ramcq

Just to clarify, there are audible glitches playing the file via GStreamer, but it does not fail.

comment:2 follow-up: Changed 13 months ago by jamrial

Could you please send the patch to the ffmpeg-devel mailing list (rebased to git head instead of ffmpeg 3.2)? Patches in this bug tracker are ignored by most developers.

comment:3 follow-up: Changed 13 months ago by cehoyos

  • Keywords libfdk added
  • Version changed from 3.2.4 to git-master

Does the sample work with the native decoder?
Please remind me of the advantage libfdk has over the native decoder.

comment:4 in reply to: ↑ 2 Changed 13 months ago by ramcq

  • Keywords libfdk removed
  • Version changed from git-master to 3.2.4

Replying to jamrial:

Could you please send the patch to the ffmpeg-devel mailing list (rebased to git head instead of ffmpeg 3.2)? Patches in this bug tracker are ignored by most developers.

Sure, will do if it seems to work after I've tested it - it's included here as a hint rather than a solution. Just thought a developer might see the issue and recognise the problem or something.

comment:5 Changed 13 months ago by ramcq

  • Keywords libfdk added
  • Version changed from 3.2.4 to git-master

comment:6 in reply to: ↑ 3 Changed 13 months ago by ramcq

Replying to cehoyos:

Does the sample work with the native decoder?

Yes it does. That's what Chromium usually uses.

Please remind me of the advantage libfdk has over the native decoder.

Patent royalties - most of AAC basic patents have expired now, and Red Hat have prepared a stripped version of fdk-aac which avoids any of the still live IP, allowing you to ship a royalty free AAC decoder and encoder pair, although not 100% accurate reproduction, it can save royalties depending what you're doing.

comment:7 follow-up: Changed 13 months ago by cehoyos

How do you fulfill FFmpeg’s license requirements?

comment:8 in reply to: ↑ 7 Changed 13 months ago by ramcq

By way of an update, I have found with ltrace that a couple of frames within the sample file are returning 0x4004 (_DECODE_FRAME_ERROR) on one frame, and later 0x400a (_UNSUPPORTED_GAIN_CONTROL_DATA) due to random file corruption I guess. GStreamer has a counter for the number of decode errors it is willing to swallow before propagating up a failure - so I believe a single failure here is causing libavcodec or ffplay to give up. Is there a different error code we should be returning from _decode_frame to make something higher up do some retries?

Replying to cehoyos:

How do you fulfill FFmpeg’s license requirements?

What are you referring to precisely? I think we should probably turn off --enable-gpl but this is just a debugging build - I don't believe we rely on anything behind this (Chromium does not afaik).

comment:9 follow-up: Changed 13 months ago by cehoyos

You are not allowed to distribute binaries based on FFmpeg source code if you used the configure option --enable-nonfree.

comment:10 in reply to: ↑ 9 Changed 13 months ago by ramcq

Replying to cehoyos:

You are not allowed to distribute binaries based on FFmpeg source code if you used the configure option --enable-nonfree.

This is getting way off-topic, but: Why does fdk-aac end up in nonfree? The Fedora / RH legal team have cleared it as free - https://fedoraproject.org/wiki/Licensing/FDK-AAC. There is some "bad smell" from Debian about it being placed in nonfree, but the history shows this is just opinion/interpretation of one guy, without any real evidence of oversight: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694257#20 (The GPL also prohibits charging a _license_ fee; just a distribution fee.)

comment:11 follow-up: Changed 13 months ago by cehoyos

You misunderstand: If you use --enable-nonfree, you are not allowed to distribute the resulting binary. Please understand that we have no means to re-instate your license to distribute FFmpeg, so if you distribute binaries compiled with --enable-nonfree, you will permanently lose the right to distribute FFmpeg.

comment:12 in reply to: ↑ 11 Changed 13 months ago by ramcq

Replying to cehoyos:

You misunderstand: If you use --enable-nonfree, you are not allowed to distribute the resulting binary. Please understand that we have no means to re-instate your license to distribute FFmpeg, so if you distribute binaries compiled with --enable-nonfree, you will permanently lose the right to distribute FFmpeg.

I spent a long time being very confused about how this was consistent with the statement at https://github.com/FFmpeg/FFmpeg/commit/47a81832 that fdk-aac can be used together with ffmpeg under an LGPL license. I eventually realised my error - somehow I had ended up with the impression that --enable-nonfree was a pre-requisite to enabling libfdk-aac, which I now see is not the case.

--enable-nonfree in fact allows you to proceed with conflicting licensed GPL and GPL-incompatible code linked together, which would indeed be not redistributable. We're not using any of the GPL parts, so I've removed --enable-nonfree from our configuration (along with --enable-gpl). Thanks for the pointer.

Now: about the bug - is there something in ffplay which would continue decoding if an error comes back from _decode_frame (within some parameters) if we return the right value?

comment:13 Changed 8 months ago by cehoyos

  • Keywords libfdk-aac added; libfdk removed

comment:14 Changed 4 months ago by ramcq

  • Resolution set to invalid
  • Status changed from new to closed

Turns out to have been a misconfigured ffmpeg, missing mp4 demuxer. Not actually a codec issue at all. Sorry for noise!

Note: See TracTickets for help on using tickets.