Opened 17 years ago

Closed 17 years ago

Last modified 17 years ago

#3634 closed defect (fixed)

Frontend crash after ffmpeg sync

Reported by: Bill <cizek@…> Owned by: Janne Grunau
Priority: critical Milestone: unknown
Component: mythtv Version: head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

After svn 13655, mythfrontend will crash when playing recordings.

If I use ac3 pass-through it works ok; If I use myth to decode the ac3 audio, mythfrontend will crash soon after the recording starts playing or after I jump forward in the video.

I've attached a gdb backtrace and frontend log. If there's anything else I can provide please let me know.

-Bill

Attachments (4)

gdb.txt (6.1 KB) - added by Bill <cizek@…> 17 years ago.
myth.log (23.6 KB) - added by Bill <cizek@…> 17 years ago.
3634_workaround.diff (665 bytes) - added by Janne Grunau 17 years ago.
disable the SSE imdct
3634_workaround_v2.diff (1.2 KB) - added by cpinkham 17 years ago.

Download all attachments as: .zip

Change History (18)

Changed 17 years ago by Bill <cizek@…>

Attachment: gdb.txt added

Changed 17 years ago by Bill <cizek@…>

Attachment: myth.log added

comment:1 in reply to:  description Changed 17 years ago by elkin@…

I can confirm that on German TV channel ProSieben?, when ac3 is send the frontend decodes badly (jerky sound) or crashes the frontend. Switching to mpg2 works flawlessly

comment:2 Changed 17 years ago by Janne Grunau

Owner: changed from Isaac Richards to Janne Grunau
Priority: minorcritical

I can reproduce this on x86_32. x86_64 works fine.

One of our modifications to libavcodec seems to be the cause. A patched ffmpeg works fine.

comment:3 Changed 17 years ago by Janne Grunau

Status: newassigned

A release build works here too.

comment:4 Changed 17 years ago by davidp@…

I have the exact same problem (with the same results from gdb backtrace). When I watch certain channels (those with AC3 as well as MP2 audio streams) it crashes the frontend.

Only crashes one of my machines though, not both of them.

comment:5 Changed 17 years ago by Bill <cizek@…>

I'm running x86_32 on a plain Intel Pentium 4.

A debug build has distorted audio as described in ticket 3608 and crashes very quickly.

A release build has the same distorted audio but doesn't crash.

If I use ac3 passthrough everything works ok.

comment:6 Changed 17 years ago by davilla@…

Same problem here with identical segfault. Video is from a HDHomeRun recording off-the-air ATSC. There's a comment about a patched ffmpeg working fine. More details on this please as the current svn trunk is broken regarding HDHomeRuns.

comment:7 Changed 17 years ago by Janne Grunau

(In [13765]) Fixes #3608. Updates ffmpeg's internal ac3 decoder

This updates the ac3 decoder in our libavcodec copy to the final patch posted on 2007-05-07 by Justin Ruggles pulls also ffmpeg revision 8816 in, since it's need by the patch. Fixes the Audio distortion reported in #3608.

Refs #3634. crashes on x86_32 with debug and release builds

Changed 17 years ago by Janne Grunau

Attachment: 3634_workaround.diff added

disable the SSE imdct

comment:8 Changed 17 years ago by Janne Grunau

3634_workaround.diff disables the SSE imdct in the ac3 decoder

comment:9 in reply to:  8 Changed 17 years ago by MaverickTech <rsmith@…>

Replying to janne:

3634_workaround.diff disables the SSE imdct in the ac3 decoder

I applied that patch and I am not seeing the SSE crash anymore, on recordings I know to be triggering a crash. I could still readily crash the frontend prior to applying the patch.

I am currently running trunk as of yesterday (13788)

comment:10 Changed 17 years ago by Anduin Withers

(In [13796]) References #3634

Force float array to align(16) for call to ff_imdct_calc_sse. The ff_imdct_calc_sse function uses movaps which will cause a GPF on unaligned data.

Another solution would be to have ff_imdct_calc_sse use movups. I'm only using the align fix as assuming correct alignment seems to be common elsewhere in there.

There may be problems with align for some versions of gcc.

comment:11 Changed 17 years ago by jppoet@…

Changeset #13796 does seem to fix this problem for me, on my Core 2 Duo Fedora i386 frontend. I also tried watching a DVD using the internal player, and that is also working fine, now.

Thanks,

John

comment:12 Changed 17 years ago by Janne Grunau

Resolution: fixed
Status: assignedclosed

fixed by [13796]

comment:13 Changed 17 years ago by Bill <cizek@…>

This fixed my problem.

Thanks, Bill

Changed 17 years ago by cpinkham

Attachment: 3634_workaround_v2.diff added

comment:14 Changed 17 years ago by cpinkham

This ticket has been closed for a while, but as indicated it can still affect people with older (aka buggy) compilers. I've attached a 3634_workaround_v2.diff file that works around the issue a different way by moving the offending variable off the stack and into a struct that is malloc-ed. This fixes the issue on my ancient gcc v3.2.2 dev system. I'm not advocating putting this hack into SVN, I just wanted to document it in case others ran into the same issue.

Note: See TracTickets for help on using tickets.