-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Any version after v2.7 (incl. v2.10.0) still crashes with MP4 containing more than one track! #71
Comments
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. 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: 8d04544 |
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 #55 https://code.videolan.org/videolan/vlc/-/issues/24913 |
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: #55 |
installing debian 11 fixed my problems |
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.
Going to investigate when I have spare cycles. |
Before some moment in 2017 Currently I can offer adding a check so that I believe, only @fabiangreffrath knows what happened in 2017. If there are no legal obstacles and no objections, etc., it is not impossible bringing |
(strictly speaking, it is not the problem of |
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 =) |
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:
Result with FAAD v2.10.0 though:
Best regards
MuldeR
The text was updated successfully, but these errors were encountered: