Modify
Warning Please read the Ticket HowTo before creating or commenting on a ticket. Failure to do so may cause your ticket to be rejected or result in a slower response.

Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#9282 closed Bug Report (Fixed)

ASF plays too fast, frontend crashes on exit

Reported by: jan@… Owned by: jyavenard
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@… 3 years ago.
-v playback log
gdb.txt (59.8 KB) - added by jan@… 3 years ago.
mythfrontend.2.log (101.1 KB) - added by jan@… 3 years ago.
-v playback,timestamp
mythfrontend_crash.log (65.1 KB) - added by jan@… 3 years ago.
Upmixing enabled, too fast playback, frontend crashes
mythfrontend_nocrash.log (48.7 KB) - added by jan@… 3 years ago.
Upmixing disabled, playback fine, no crash
9282.diff (18.9 KB) - added by jyavenard 3 years ago.
Patches for 0.24-fixes

Download all attachments as: .zip

Change History (22)

Changed 3 years ago by jan@…

-v playback log

comment:2 Changed 3 years ago by tralph

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

Changed 3 years ago by jan@…

Changed 3 years ago by jan@…

-v playback,timestamp

comment:3 Changed 3 years ago by jan@…

Backtrace and extended log have been uploaded.

comment:4 Changed 3 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 3 years ago by tralph

  • Status changed from new to 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 3 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 3 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 3 years ago by tralph

  • Owner set to jyavenard

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 3 years ago by jan@…

Upmixing enabled, too fast playback, frontend crashes

Changed 3 years ago by jan@…

Upmixing disabled, playback fine, no crash

comment:10 Changed 3 years ago by jan@…

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

comment:11 Changed 3 years ago by jyavenard

  • Priority changed from minor to 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:12 Changed 3 years ago by jyavenard

In [27358] fix the memory corruption issue.

comment:13 Changed 3 years ago by jyavenard

  • Component changed from MythTV - General to MythTV - Audio Output

comment:14 Changed 3 years ago by jyavenard

  • Resolution set to Fixed
  • Status changed from infoneeded_new to 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,

Changed 3 years ago by jyavenard

Patches for 0.24-fixes

comment:15 Changed 3 years ago by jyavenard

Thank you for testing extensively 9282.diff on 0.24-fixes. Will backport if all goes well next week

comment:16 Changed 3 years ago by jyavenard

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

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'new'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.