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: jan@… 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)

mythfrontend.log (68.9 KB) - added by jan@… 13 years ago.
-v playback log
gdb.txt (59.8 KB) - added by jan@… 13 years ago.
mythfrontend.2.log (101.1 KB) - added by jan@… 13 years ago.
-v playback,timestamp
mythfrontend_crash.log (65.1 KB) - added by jan@… 13 years ago.
Upmixing enabled, too fast playback, frontend crashes
mythfrontend_nocrash.log (48.7 KB) - added by jan@… 13 years ago.
Upmixing disabled, playback fine, no crash
9282.diff (18.9 KB) - added by JYA 13 years ago.
Patches for 0.24-fixes

Download all attachments as: .zip

Change History (22)

Changed 13 years ago by jan@…

Attachment: mythfrontend.log added

-v playback log

comment:2 Changed 13 years ago by tralph

Jan, Please povide another log with -v playback,timestamp.

Changed 13 years ago by jan@…

Attachment: gdb.txt added

Changed 13 years ago by jan@…

Attachment: mythfrontend.2.log added

-v playback,timestamp

comment:3 Changed 13 years ago by jan@…

Backtrace and extended log have been uploaded.

comment:4 Changed 13 years ago by tralph

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 tralph

Status: newinfoneeded_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 jan@…

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 tralph

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 tralph

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 jan@…

Attachment: mythfrontend_crash.log added

Upmixing enabled, too fast playback, frontend crashes

Changed 13 years ago by jan@…

Attachment: mythfrontend_nocrash.log added

Upmixing disabled, playback fine, no crash

comment:10 Changed 13 years ago by jan@…

Upmixing is indeed the culprit. See the new frontend logs.

comment:11 Changed 13 years ago by JYA

Priority: minormajor

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:12 Changed 13 years ago by JYA

In [27358] fix the memory corruption issue.

comment:13 Changed 13 years ago by JYA

Component: MythTV - GeneralMythTV - Audio Output

comment:14 Changed 13 years ago by JYA

Resolution: Fixed
Status: infoneeded_newclosed

(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,

Changed 13 years ago by JYA

Attachment: 9282.diff added

Patches for 0.24-fixes

comment:15 Changed 13 years ago by JYA

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 JYA

(In [27394]) backport [27358-27359],[27368-27369],[27390]. Fixes #9282. Bump API, require recompiling all mythplugins.

Note: See TracTickets for help on using tickets.