mixxx
mixxx copied to clipboard
mixxxdj
Windows MediaFoundation: Unhandled M4A/AAC decoding error
Reported by: fkbreitl Date: 2020-10-10T07:42:45Z Status: Confirmed Importance: High Launchpad Issue: lp1899242 Tags: aac, m4a, soundsource, windows Attachments: [Orjan Nilsen - Endymion (Original Mix)-wKl0dRGfVo4-10s.m4a](https://bugs.launchpad.net/bugs/1899242/+attachment/5420336/+files/Orjan Nilsen - Endymion (Original Mix)-wKl0dRGfVo4-10s.m4a)
I have attached an example of some files that crash Mixxx 2.3 on Windows 10 v1909.
The last message I see is:
Fast analysis: false
Debug [AnalyzerThread 5 mixxxdj/mixxx#4915]: Key calculation started with plugin "qm-keydetector:2"
DEBUG ASSERT: "m_currentFrameIndex == readerFrameIndex" in function class mixxx::ReadableSampleFrames __cdecl mixxx::SoundSourceMediaFoundation::readSampleFramesClamped(class mixxx::WritableSampleFrames) at ..\src\sources\soundsourcemediafoundation.cpp:365
Commented by: fkbreitl Date: 2020-10-10T07:42:45Z Attachments: [Orjan Nilsen - Endymion (Original Mix)-wKl0dRGfVo4-10s.m4a](https://bugs.launchpad.net/mixxx/+bug/1899242/+attachment/5420336/+files/Orjan Nilsen - Endymion (Original Mix)-wKl0dRGfVo4-10s.m4a)
Commented by: uklotzde Date: 2020-10-11T12:26:22Z
The new, hardened FFpmeg decoder reveals that this file has a disontinuity when decoding:
Warning [CachingReaderWorker 1]: ReadAheadFrameBuffer - Overlapping range [21502 -> 21503) in output buffer [21503 -> 24576) with input buffer [21502 -> 22526)
Unfortunately, I neither have the time nor the development environment for investigating how to handle this correctly in the Windows MediaFoundation decoder.
The issue should already be present in the 2.2.x versions and the debug assertion that occurs in the debug build might not cause any major playback issues in the release build.
Commented by: fkbreitl Date: 2020-10-11T15:31:10Z
Thanks for sorting this out. Do discontinuities indicate a serious problem of such files or is this rather a technical issue which is hard to notice? Are there any tools for checking and correcting files with discontinuities?
Commented by: fkbreitl Date: 2020-11-06T18:44:49Z
Unfortunately this happens for many files which makes testing new builds difficult. How can we be sure that this will not cause a problem in the release build? Is it possible to suppress this error in the debug builds? To Windows users this seems quite problematic.
Commented by: uklotzde Date: 2020-11-06T19:23:00Z
The debug assertion is a guard and reminder that the code does not handle those unexpected discontinuities, neither gaps nor overlaps in the decoded audio data. After such a point the tracked position does no longer match the position reported by the decoder.
A Windows developer needs to look into this and add the appropriate error handling for broken/corrupt files. I strongly recommend not to remove the debug assertion before this code is in place!
Commented by: fkbreitl Date: 2020-11-06T21:09:35Z
It sounds like this is a critical issue for the next release. In this case I suggest to increase the "importance" to high.
Moreover it would also be important to be able to switch off this debug assertion to continue testing. Could such a command line switch be added?
Commented by: uklotzde Date: 2020-11-06T21:26:45Z
The code has not been modified since the 2.2 release. We can't wait for a Windows developer to step in. This issue only affects broken/corrupt files. I don't consider this a release blocker. Otherwise, we would need to disable M4A decoding on Windows entirely until a fix is available.
We compile all debug version on CI with debug_assertions_fatal=1/-DDEBUG_ASSERTIONS_FATAL=ON without exceptions.
Commented by: fkbreitl Date: 2020-11-06T23:10:28Z
I don't think the files are corrupt or broken but this is false alarm. The files show no issues with other software.
We compile all debug version on CI with debug_assertions_fatal=1/-DDEBUG_ASSERTIONS_FATAL=ON without exceptions.
Then a switch to disable debugging is overdue.
Commented by: Be-ing Date: 2021-02-04T20:53:10Z
FFMPEG support is now available on Windows with the new vcpkg build environment. Shall we go ahead and follow the TODO comments in SoundSourceProviderFFmpeg::getPriorityHint and raise the priority of FFmpeg above MediaFoundation? Will this shift users' cue points and beatgrids? https://github.com/mixxxdj/mixxx/pull/3617
Commented by: uklotzde Date: 2021-02-07T00:11:27Z
Decoding with SoundSourceFFmpeg works without audible artifacts, but many subsequent frames are overlapping by 24 samples each:
warning [CachingReaderWorker 1] ReadAheadFrameBuffer - Overlapping range [73723 -> 73724) in output buffer [73724 -> 73728) with input buffer [73723 -> 74747) warning [CachingReaderWorker 1] ReadAheadFrameBuffer - Overlapping range [89082 -> 89083) in output buffer [89083 -> 90112) with input buffer [89082 -> 90106) warning [CachingReaderWorker 1] ReadAheadFrameBuffer - Overlapping range [104441 -> 104442) in output buffer [104442 -> 106496) with input buffer [104441 -> 105465) warning [CachingReaderWorker 1] ReadAheadFrameBuffer - Overlapping range [111608 -> 111609) in output buffer [111609 -> 114688) with input buffer [111608 -> 112632) warning [CachingReaderWorker 1] ReadAheadFrameBuffer - Overlapping range [126967 -> 126968) in output buffer [126968 -> 131072) with input buffer [126967 -> 127991) warning [CachingReaderWorker 1] ReadAheadFrameBuffer - Overlapping range [142326 -> 142327) in output buffer [142327 -> 147456) with input buffer [142326 -> 143350) warning [CachingReaderWorker 1] ReadAheadFrameBuffer - Overlapping range [157685 -> 157686) in output buffer [157686 -> 163840) with input buffer [157685 -> 158709) warning [CachingReaderWorker 1] ReadAheadFrameBuffer - Overlapping range [172020 -> 172021) in output buffer [172021 -> 172032) with input buffer [172020 -> 173044) warning [CachingReaderWorker 1] ReadAheadFrameBuffer - Overlapping range [193523 -> 193524) in output buffer [193524 -> 196608) with input buffer [193523 -> 194547) warning [CachingReaderWorker 1] ReadAheadFrameBuffer - Overlapping range [207858 -> 207859) in output buffer [207859 -> 212992) with input buffer [207858 -> 208882) warning [CachingReaderWorker 1] ReadAheadFrameBuffer - Overlapping range [223217 -> 223218) in output buffer [223218 -> 229376) with input buffer [223217 -> 224241) warning [CachingReaderWorker 1] ReadAheadFrameBuffer - Overlapping range [253935 -> 253936) in output buffer [253936 -> 253952) with input buffer [253935 -> 254959) warning [CachingReaderWorker 1] ReadAheadFrameBuffer - Overlapping range [269294 -> 269295) in output buffer [269295 -> 270336) with input buffer [269294 -> 270318) warning [CachingReaderWorker 1] ReadAheadFrameBuffer - Overlapping range [283629 -> 283630) in output buffer [283630 -> 286720) with input buffer [283629 -> 284653) warning [CachingReaderWorker 1] ReadAheadFrameBuffer - Overlapping range [297964 -> 297965) in output buffer [297965 -> 303104) with input buffer [297964 -> 298988) warning [CachingReaderWorker 1] ReadAheadFrameBuffer - Overlapping range [313323 -> 313324) in output buffer [313324 -> 319488) with input buffer [313323 -> 314347) warning [CachingReaderWorker 1] ReadAheadFrameBuffer - Overlapping range [329706 -> 329707) in output buffer [329707 -> 335872) with input buffer [329706 -> 330730) warning [CachingReaderWorker 1] ReadAheadFrameBuffer - Overlapping range [344041 -> 344042) in output buffer [344042 -> 344064) with input buffer [344041 -> 345065) warning [CachingReaderWorker 1] ReadAheadFrameBuffer - Overlapping range [352232 -> 352233) in output buffer [352233 -> 352256) with input buffer [352232 -> 353256) warning [CachingReaderWorker 1] ReadAheadFrameBuffer - Overlapping range [373735 -> 373736) in output buffer [373736 -> 376832) with input buffer [373735 -> 374759) warning [CachingReaderWorker 1] ReadAheadFrameBuffer - Overlapping range [389094 -> 389095) in output buffer [389095 -> 393216) with input buffer [389094 -> 390118) warning [CachingReaderWorker 1] ReadAheadFrameBuffer - Overlapping range [404453 -> 404454) in output buffer [404454 -> 409600) with input buffer [404453 -> 405477) warning [CachingReaderWorker 1] ReadAheadFrameBuffer - Overlapping range [412644 -> 412645) in output buffer [412645 -> 417792) with input buffer [412644 -> 413668) warning [CachingReaderWorker 1] ReadAheadFrameBuffer - Overlapping range [428003 -> 428004) in output buffer [428004 -> 434176) with input buffer [428003 -> 429027) info [CachingReaderWorker 1] SoundSourceFFmpeg - Stream ends at sample frame 441315 instead of 441344 debug [CachingReaderWorker 1] SoundSourceFFmpeg - Padding remaining output buffer with silence [441315 -> 441344)
In this case the decoder simply replaces the previously decoded samples with the new samples. If the play position is already beyond the overlapping region then the overlapping samples are skipped and discarded.
Commented by: uklotzde Date: 2021-02-21T21:29:19Z
How to test: Replace one of the Mixxx test files (e.g. src/test/id3-test-data/cover-test-ffmpeg-aac.m4a) with the .m4a file attached to this bug and run the test.
- Debug assertion disabled: Tests are failing with differing sample values
- Set m_currentFrameIndex = readerFrameIndex in any case: Tests are failing due to differing stream length (in samples)
Commented by: dan-giddins Date: 2021-02-21T21:57:47Z
Just a recap of the core issue that I recorded here https://github.com/mixxxdj/mixxx/pull/3617:
The source reader gives us a constant sampleDuration for every sample frame, but sometimes advances the sampleTime value such the the difference between the current and previous sampleTime values is significantly different enough to from the sampleDuration. This value is then converted from the 'Time' domain to the 'Sample' domain, and then the position of the start of next frame (according to the source reader) does not match up with the regular number of samples we expect to have moved forward by.
This also only seems to happen for some files... and it will only happen at some point going though the file, but constantly at the same point.
Commented by: Be-ing Date: 2021-03-08T20:41:10Z
So are we doing anything about this for 2.3 or just turning off DEBUG_ASSERTIONS_FATAL?
Commented by: dan-giddins Date: 2021-03-08T21:34:58Z
I don't think there is anything we can do about this, other than using something other than Microsoft Media Foundation...
I can do some testing with that DEBUG_ASSERTIONS_FATAL disabled and see if its still stable?
Commented by: Be-ing Date: 2021-03-09T00:09:53Z
Considering the lack of users saying this has been an issue with 2.2, I think it is working well enough that people don't notice without DEBUG_ASSERTIONS_FATAL.