faad2
faad2 copied to clipboard
knik0
Any version after v2.7 (incl. v2.10.0) still crashes with MP4 containing more than one track!
Hello,
as the title says, I am still locked to old version 2.7, because it seems to be the last "good" version that doesn't crash while trying to decode an MP4 file that contains more than just a single audio track - as is the case with pretty much any MP4 video file!
Example MP4 file that can be used to reproduce crash: https://www.mediafire.com/file/pu1t25to5q0ogyh/soothsayer.mp4.zip/file
(but I think pretty much an MP4 file with video+audio track would do!)
To reproduce:
faad.exe -o test.wav soothsayer.mp4
Expected result, as with FAAD v2.7:
*********** Ahead Software MPEG-4 AAC Decoder V2.7 ******************
Build: Mar 26 2017
Copyright 2002-2004: Ahead Software AG
http://www.audiocoding.com
Floating point version
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License.
**************************************************************************
soothsayer.mp4 file info:
LC AAC 286.510 secs, 2 ch, 44100 Hz
unknown: 0
unknown: 287300
unknown: B4A7DDA45MH1341528066551075
unknown: o-o.preferred.fra07t12.v5.cache3.c.youtube.com
---------------------
| Config: 2 Ch |
---------------------
| Ch | Position |
---------------------
| 00 | Left front |
| 01 | Right front |
---------------------
Decoding soothsayer.mp4 took: 1.03 sec. 277.63x real-time.
Result with FAAD v2.10.0 though:
*********** Ahead Software MPEG-4 AAC Decoder V2.10.0 ******************
Build: Jan 23 2021
Copyright 2002-2004: Ahead Software AG
http://www.audiocoding.com
bug tracking: https://sourceforge.net/p/faac/bugs/
Floating point version
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License.
**************************************************************************
**** MP4 header ****
Brand: mp42(version 0)
Compatible brands: isomavc1mp42
*track media type: 'soun': OK
Modification Time: Tue May 4 02:23:33 2010
Samplerate: 44100
Total samples: 12647424
Total channels: 2
Bits per sample: 16
Buffer size: 613
Max bitrate: 145176
Average bitrate: 125480
Samples per frame: 0
Frames: 12351
ASC size: 2
Duration: 286.8 sec
Data offset/size: 15546/0
********************
----------tag list-------------
'gsst' : 0
'gstd' : 287300
'gssd' : B4A7DDA45MH1341528066551075
'gshh' : o-o.preferred.fra07t12.v5.cache3.c.youtube.com
-------------------------------
soothsayer.mp4 file info:
LC AAC 286.790 secs, 2 ch, 44100 Hz
---------------------
| Config: 2 Ch |
---------------------
| Ch | Position |
---------------------
| 00 | Left front |
| 01 | Right front |
---------------------
0% decoding soothsayer.mp4.
***crash***
Best regards MuldeR
I am experiencing this issue as well.
To prevent manual compilation of the old version, I am using the .deb files from Ubuntu 14.04. Direct link for amd64
Still, an updated version supporting multiple tracks again would be greatly appreciated.
thank you for letting me realise there is faad binary created for stand alone testing/troubleshooting
ive tracked down the commit that brings in this problem: 8d045444cb72091b8b479684ffe7ee8e662afb43
this file can be used to to recreate seems ur mediafire one is gone https://www2.iis.fraunhofer.de/AAC/ChID-BLITS-EBU.mp4
please also see my posts https://github.com/knik0/faad2/issues/55 https://code.videolan.org/videolan/vlc/-/issues/24913
ive tracked down the commit that brings in this problem: 8d04544
Well, this is pretty much the most obvious commit, as it replaces the entire MP4 format handling library. 🤷
@fabiangreffrath well if you want more details, as i investigated this much more, please look at my main issue comments: https://github.com/knik0/faad2/issues/55
Hm, but Debian 11 has 2.10.0, though with one additional patch backported from this repository.
The MP4 code has been completely rewritten after 2.7 and from what I can see it just assumes that the table listing the position of each audio frame and assumes that the "atom" is a continuous of audio frames. Any other data interleaved with the audio track like video, other audio tracks, etc will cause the decoder to fail.
Just checked with tip-of-tree build. It does not crash anymore, but it does not decode too.
**** MP4 header ****
Brand: avc1(version 0)
Compatible brands: isomavc1
*track media type: 'vide': unsupported, skipping
*track media type: 'soun': OK
Modification Time: Thu May 17 00:56:13 2012
Samplerate: 44100
Total samples: 2056192
Total channels: 2
Bits per sample: 16
Buffer size: 3840
Max bitrate: 170896
Average bitrate: 159992
Samples per frame: 0
Frames: 1004
ASC size: 4
Duration: 46.6 sec
Data offset/size: 78e4/0
********************
parse error: atom 'udta' not found
can't read atom name @10c690
/redacted/ChID-BLITS-EBU.mp4 file info:
LC AAC 46.626 secs, 6 ch, 44100 Hz
---------------------
| Config: 5.1 Ch | WARNING: channels are reordered according to
--------------------- MS defaults defined in WAVE_FORMAT_EXTENSIBLE
| Ch | Position |
---------------------
| 00 | Center front |
| 01 | Left front |
| 02 | Right front |
| 03 | Left back |
| 04 | Right back |
| 05 | LFE |
---------------------
Going to investigate when I have spare cycles.
Before some moment in 2017 mp4ff stream parser was used. It supported tracks. Later it was replaced with mp4util.
The later does not support tracks -- its codebase is 3x smaller, 1KLoC vs 3KLoC; not unlikely some other stream features are not supported as well.
Currently I can offer adding a check so that faad executable will honestly admit that multi-track media is not supported and gracefully exit.
I believe, only @fabiangreffrath knows what happened in 2017. If there are no legal obstacles and no objections, etc., it is not impossible bringing mp4ff back...
(strictly speaking, it is not the problem of libfaad, but rather the problem of frontend)
Honestly, I don't know either. I am just the only one left with commit rights to this repository. I remember that @knik0 took over the code base from Menno back then and created this repository. I already had commit rights at this time, because I was the maintainer for the libfaad2 Debian package and was allowed to contribute some downstream patches back. I think @knik0 decided to replace the mp4ff library with some simpler solution because of a number of security issues with the former, but I am not sure.
Whatever, I think the frontend displaying a short text explaining that it cannot support tracks in its current state and pointing the user to some more advanced application is the best we can do now.
Found quicktime format specification, and now mp4 code is not abracadabra for me =)
Only one piece seems to be missing (parsing stsc) to fix the issue. Will try to implement it this week.