Opened 13 years ago
Closed 13 years ago
Last modified 13 years ago
#9282 closed Bug Report (Fixed)
ASF plays too fast, frontend crashes on exit
Reported by: | Owned by: | JYA | |
---|---|---|---|
Priority: | major | Milestone: | unknown |
Component: | MythTV - Audio Output | Version: | 0.24-fixes |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
What the summary says. Playing an ASF file plays it far too fast, and if I exit this video, mythfrontend crashes with the following error:
mythfrontend.real: audiooutputbase.cpp:138: virtual AudioOutputBase::~AudioOutputBase?(): Assertion `memory_corruption_test1 == 0xdeadbeef' failed.
Attachments (6)
Change History (22)
Changed 13 years ago by
Attachment: | mythfrontend.log added |
---|
comment:1 Changed 13 years ago by
http://svn.mythtv.org/trac/wiki/TicketHowTo
Please provide a backtrace http://www.mythtv.org/docs/mythtv-HOWTO-22.html#ss22.2
comment:4 Changed 13 years ago by
Jan, the video frame rate and associated timestamps look correct. The problem appears to be related to the audio timestamps. Either the audio is being played to fast or the timestamp generation is broken. A sample will be needed to determine if this is something that can be fixed in the player or a broken video.
Please provide a 50MB sample clip using the following:
dd if=inputfile of=sampefile bs=1024 count=50000
and upload the http://filebin.ca
comment:6 Changed 13 years ago by
Status: | new → infoneeded_new |
---|
Jan, the video plays back perfectly on 2 different systems here. I believe you are having issues with your audio configuration. When you upgrade to 0.24-fixes it is required for you to enter setup, scan your audio devices and reconfigure you audio. Also JYA back-ported numerous audio fixes recently so make sure you update to the very latest 0.24-fixes then rescan and reconfigure your audio. Please let us know if this resolved your playback issues or not. It's probably why you have a segfault too.
comment:7 Changed 13 years ago by
I've updated (to rev 27339) and re-configured the audio output. No change, the audio still plays too fast, the frontend still crashes on exit.
comment:8 Changed 13 years ago by
Jan, I noticed you are sending this to a digital output (IEC). Do you have upmixing enabled? If so, can you disable upmixing and see if that helps. Please provide a new log with -v playback,audio,extra.
comment:9 Changed 13 years ago by
Owner: | set to JYA |
---|
JYA, please take a look at this one. This video plays back fine on all my systems. The user is running a digital output device and the audio isn't playing back properly. It also seems to segfault due to audio issues.
Changed 13 years ago by
Attachment: | mythfrontend_crash.log added |
---|
Upmixing enabled, too fast playback, frontend crashes
Changed 13 years ago by
Attachment: | mythfrontend_nocrash.log added |
---|
Upmixing disabled, playback fine, no crash
comment:11 Changed 13 years ago by
Priority: | minor → major |
---|
upmixing isn't the culprit I'm afraid, but how it is called, and in this case is just a consequence of a big .
Audio buffer is by design to be 32kWords long (128kB long if using floats or 32 bits samples). With this particular sample, AddFrames? is sometimes called with a buffer that is 73kWord.
There's a clear mismatch between what avfd asks ffmpeg to decode, and the size of the buffer allocated to receive the decoded samples.
Need more investigation
comment:13 Changed 13 years ago by
Component: | MythTV - General → MythTV - Audio Output |
---|
comment:14 Changed 13 years ago by
Resolution: | → Fixed |
---|---|
Status: | infoneeded_new → closed |
(In [27368]) Fixes #9282. This ticket revealed massive issues with a few of the classes used with the audio framework.
- Resampler used a 32k and 128k statically allocated buffer. If the resampling ratio was greater than 4, memory corruption would occur. The resampler now uses a dynamically allocated memory buffer that is increased when required and freed when the audio class is closed.
- Float audio processing, if the samples received were greater than the statically allocated buffer (32k), memory corruption would occur. The audio float processing is now done in 32k blocks at a time that guarantee no memory overflow can occur.
- Audio upmixer uses a statically allocated buffer (8192 bytes). If the samples converted were greater than 8k, corruption would occur. The upmixer is now called iteratively 8k at a time.
- AC3 encoder uses a staticaly allocted buffer (128k). If the samples converted were greater than 128k, audio data would be loss and audio buffer would be left in an undetermine state. The AC3 encoder is now called in blocks according to how many free space exists in the AC3 encoder buffer.
All issues mentioned above are corner cases scenarios and unlikely to be experienced by the user ; typically the size of audio frames received at a given time is typically between 80 and 300 bytes. However, in theory ffmpeg can decode and provide samples of up to 190kB. In the sample provided in #9282 (WM3 audio codec), the audio framework is called with 60-90kB of samples triggering most of the bugs mentioned above. The resampler, upmixer and AC3 encoder has been in use in myth for several years, yet the issue had never been seen up to now. Now that was fun... Spent a whole week-end tracing what was going on. The ideal solution would be to change all the sub-classes so they do not work with static size buffer and be able to work with anything you throw at the,
comment:15 Changed 13 years ago by
Thank you for testing extensively 9282.diff on 0.24-fixes. Will backport if all goes well next week
comment:16 Changed 13 years ago by
(In [27394]) backport [27358-27359],[27368-27369],[27390]. Fixes #9282. Bump API, require recompiling all mythplugins.
-v playback log