Skip to content
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

Enable SoundSourceFFmpeg as a fallback for broken FAAD v2.9.1 #2738

Merged
merged 10 commits into from
May 1, 2020
Merged

Enable SoundSourceFFmpeg as a fallback for broken FAAD v2.9.1 #2738

merged 10 commits into from
May 1, 2020

Conversation

uklotzde
Copy link
Contributor

@uklotzde uklotzde commented Apr 29, 2020

SoundSourceM4A fails to decode any audio data after successfully opening the file. Mixxx loads .m4a files but then displays an empty waveform and the audio stream becomes empty after trying to decode it.

This PR adds a basic read test to verify that the audio stream is actually readable. Otherwise sound sources with a lower priority get the chance to open the file. This wasn't possible before.

Tested with Fedora 32. RPMFusion distributes the broken FAAD v2.9.1 library like Arch does.

A backport to 2.2.x would be nice, but requires too much work. If anyone feels responsible to do this feel free to take this commit as a starting point. I will not invest any time to do this, neither for the implementation nor for a review!

Links:
https://www.mixxx.org/forums/viewtopic.php?f=3&t=13102
https://www.mixxx.org/forums/viewtopic.php?f=3&t=13157

@uklotzde uklotzde added this to the 2.3.0 milestone Apr 29, 2020
@daschuer
Copy link
Member

Here is the upstream discussion for reference.
knik0/faad2@920ec98
knik0/faad2@a8dc3f8

@daschuer
Copy link
Member

I am afraid the issue will spread, because Ubuntu Focal seems to be effected as well:
https://packages.ubuntu.com/focal/libfaad2

@daschuer
Copy link
Member

Can one confirm the issue on Ubuntu?
Maybe the package maintainer can help.
@fabiangreffrath Can you?

Copy link
Member

@daschuer daschuer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good step for reliability.

Unfortunately it creates a bad situation for the current problem, because most likely faad and ffmpeg will have different offsets. So this will mess up the beat-grids after upgrading to an effected distro and will mess up the beat grids again after the issue has been fixed.

src/sources/audiosource.cpp Outdated Show resolved Hide resolved
src/sources/soundsourceproxy.cpp Outdated Show resolved Hide resolved
src/sources/soundsourceproxy.cpp Show resolved Hide resolved
src/sources/soundsourceproxy.cpp Outdated Show resolved Hide resolved
@daschuer
Copy link
Member

@uklotzde can you verify if there is an offset issue?

How does this relate to the deprecation of libmp4v2
https://bugs.launchpad.net/mixxx/+bug/1842208

src/sources/soundsourceproxy.cpp Outdated Show resolved Hide resolved
src/sources/soundsourceproxy.cpp Show resolved Hide resolved
@daschuer
Copy link
Member

daschuer commented May 1, 2020

Do you have some insights about the topics I have raised above?

How many files are effected?
Is the an offset issue?

@uklotzde
Copy link
Contributor Author

uklotzde commented May 1, 2020

No, I haven't checked the offsets and I cannot make general statements. I'm using FFmpeg and have already upgraded to Fedora 32 where FAAD2 is broken. I need to build in a VM for verifying a few example files. The offset may vary for different iTunes encoder versions and I am not able to test all possible variations.

The outcome of this investigation doesn't matter for this PR. This fallback solution affects all file formats. The decision about how to deal with the FAAD2 situation in particular is a separate topic.

@daschuer
Copy link
Member

daschuer commented May 1, 2020

The decision about how to deal with the FAAD2 situation in particular is a separate topic.

Yes, under normal circumstance you are right. But we should be aware what it means for the user.
I think I can perform the test here. Do you have broken files or are all of them broken?

@daschuer
Copy link
Member

daschuer commented May 1, 2020

This LGTM, but we should hold it of until we know what will happen on the users system.

@uklotzde
Copy link
Contributor Author

uklotzde commented May 1, 2020

I have tested with a single file from the iTunes Store. No visible or audible offsets when switching from FAAD2 to FFmpeg.

While testing and copying the Mixxx library from the VM and relinking the music folder to a different location I discovered a wrong debug assertion. Fixed.

@uklotzde
Copy link
Contributor Author

uklotzde commented May 1, 2020

Users are currently unable to play their .m4a files! I don't see any reason why we should hold this back??

@daschuer
Copy link
Member

daschuer commented May 1, 2020

No visible or audible offsets when switching from FAAD2 to FFmpeg.

Good to know. So we have nothing else to do here. Thank you for testing.

@daschuer
Copy link
Member

daschuer commented May 1, 2020

Waiting for CI

@Holzhaus
Copy link
Member

Holzhaus commented May 1, 2020

In case there are offsets, we could just switch to FFmpeg for M4A unconditionally. That would allow us to update all positions for M4A files in the database via a schema migration.

@Holzhaus
Copy link
Member

Holzhaus commented May 1, 2020

Do you have broken files or are all of them broken?

Converted a WAV file to M4A via ffmpeg version n4.2.2:

ffmpeg -i somefile.wav somefile.m4a

I can't play this file with FAAD.

@daschuer
Copy link
Member

daschuer commented May 1, 2020

CI failure is a timout.

@daschuer
Copy link
Member

daschuer commented May 1, 2020

LGTM

@daschuer daschuer merged commit c894af6 into mixxxdj:master May 1, 2020
@uklotzde uklotzde deleted the audio_source_verify_readable branch May 1, 2020 16:18
@fabiangreffrath
Copy link

Could you guys please check if this issue persists with FAAD2 2.9.2 which I have just released yesterday?

@uklotzde
Copy link
Contributor Author

uklotzde commented May 5, 2020

@fabiangreffrath I have installed the RPMFusion package for f32 and still get known error "AAC decoding error: 21 Unexpected channel configuration change".

Decoding manually using faad works though!?

@fabiangreffrath
Copy link

Decoding manually using faad works though!?

Is this an actual question?

@Piscium
Copy link

Piscium commented Jun 7, 2020

Could you guys please check if this issue persists with FAAD2 2.9.2 which I have just released yesterday?

Issue still exists with FAAD2 2.9.2 and Mixxx 2.2.4 in Arch. I have thousands of files with this issue that cannot played in Mixxx but play just fine in Audacious, VLC and Quodlibet.

@fabiangreffrath
Copy link

But doesn't VLC also use faad2 internally? Though, they apply a couple of patches. Could one of them make the difference?

https://github.com/videolan/vlc/tree/master/contrib/src/faad2

@Piscium
Copy link

Piscium commented Jun 7, 2020

But doesn't VLC also use faad2 internally? Though, they apply a couple of patches. Could one of them make the difference?

I am playing a m4a file with VLC as I write this. If I press Ctrl J to go to the Current Media Information window, Codec tab, it says:
Codec: MPEG AAC Audio (mp4a)

I don't know if that is FAAD or some other codec.

Edit: corrected typos

@uklotzde
Copy link
Contributor Author

uklotzde commented Jun 7, 2020

VLC seems to be using a workaround for this bug: https://github.com/videolan/vlc/blob/b3fe59fad88112045e8c5ddda325fb3a06a2843e/modules/codec/faad.c#L354

@fabiangreffrath Is this a bug or intended behavior? It didn't occur with all versions up to 2.8.8.

@Piscium
Copy link

Piscium commented Jun 7, 2020

Btw, I did a quick test of the git Mixxx master using the Arch AUR git package and it works fine with respect to this issue.

@uklotzde
Copy link
Contributor Author

uklotzde commented Jun 7, 2020

@Piscium It might only work because FFmpeg is used as a fallback.

@fabiangreffrath
Copy link

@uklotzde The code was changed to fix a vulnerability. I guess the library is more strict regarding standards compliance now, but this leads to compatibility issues.

Please note that I am not the real maintainer for faad2. I am just the last person alive left with commit rights to the repository.

fabiangreffrath referenced this pull request in knik0/faad2 Jun 8, 2020
Implicit channel mapping reconfiguration is explicitely forbidden by
ISO/IEC 13818-7:2006 (8.5.3.3). Decoders should be able to detect such
files and reject them. FAAD2 does not perform any kind of checks
regarding this.

This leads to security vulnerabilities when processing crafted AAC
files performing such reconfigurations.

Add checks to decode_sce_lfe and decode_cpe to make sure such
inconsistencies are detected as early as possible.

These checks first read hDecoder->frame: if this is not the first
frame then we make sure that the syntax element at the same position
in the previous frame also had element_id id_syn_ele. If not, return
21 as this is a fatal file structure issue.

This patch addresses CVE-2018-20362 (fixes #26) and possibly other
related issues.
@fabiangreffrath
Copy link

Could someone please point me to a sample file that should play (and played before FAAD 2.8.8) but doesn't play now anymore?

@uklotzde
Copy link
Contributor Author

@fabiangreffrath
Copy link

Thank you, but I cannot seem to reproduce the issue with this file and FAAD 2.9.2:

./frontend/faad.exe ../sample2ch.m4a -o out.wav
 *********** Ahead Software MPEG-4 AAC Decoder V2.9.2 ******************

 Build: Jun 25 2020
 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 1)
Compatible brands:      mp42mp41
*track media type: 'soun': OK
Modification Time:              Fri Feb 04 23:31:11 2011

Samplerate:             48000
Total samples:          971776
Total channels:         2
Bits per sample:        16
Buffer size:            6144
Max bitrate:            192000
Average bitrate:        192000
Samples per frame:      0
Frames:                 949
ASC size:               2
Duration:               20.2 sec
Data offset/size:       16f9/0
********************
parse error: atom 'udta' not found
can't read atom name @578fb
../sample2ch.m4a file info:

LC AAC  20.245 secs, 2 ch, 48000 Hz

  ---------------------
 | Config:  2 Ch       |
  ---------------------
 | Ch |    Position    |
  ---------------------
 | 00 | Left front     |
 | 01 | Right front    |
  ---------------------

Decoding ../sample2ch.m4a took:  0.08 sec. 259.56x real-time.

@Piscium
Copy link

Piscium commented Jun 26, 2020

I am on Linux so cannot easily run a Windows exe. This is the sort of file I had problems with, I have thousands of files like this. It is encrypted and the password is
faadissue

After unencrypting add the extension m4a.

sample.zip

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants