Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#3312 closed defect (invalid)

Recording kills mythfrontend with Standard decoder but is OK with libmpeg2

Reported by: anonymous Owned by: Isaac Richards
Priority: minor Milestone: unknown
Component: mythtv Version: 0.20-fixes
Severity: medium Keywords: mythfrontend preview ffmpeg libmpeg2 crash atsc
Cc: Ticket locked: no


I use 0.20-fixes (ATrpms 0.155 r13228). I have an ATSC recording the playback of which, at a certain point during it, is guaranteed to kill mythfrontend whether via the preview video window or during actual playback. Some facts:

  • The issue only occurs with the Standard (ffmpeg) decoder. It does not happen with libmpeg2.
  • I do not use XvMC.
  • The issue exists at least as far back as ATrpms 0.151.
  • The moment is located about one second after the recording's start. Before the recording began, the card had previously been used to record from the local PBS affiliate's HD channel, which happens to be off the air during daytime hours. During these hours the station displays a blue screen with a message saying so.
  • With the libmpeg2 decoder, as the recording starts, this message appears; then, as the ATSC card changes to the proper channel, the screen turns black for a half second before playback resumes. When advancing through this segment frame by frame, there is no such half-second black segment (the blue screen immediately shifts, albeit wiht a couple of frames of compression blocks, to the video from the correct channel), so I presume that the segment causes mythfrontend to hiccup as it figures out what to do. (At least a hiccup is better than a full-blown crash.)
  • With the Standard decoder, instead of the black-screen hiccup, the screen (whether during full playback or in the preview video window) turns green just before the crash.
  • I've seen similar glitches a few other times over the past year when recording from the aforementioned PBS HD channel a program that starts right when the channel comes back on the air. Usually there's no crash, although I can't always be sure I've been using Standard; I've alternated between the two many times.

If desired, I can try to post the problematic recording snippet somewhere.

Change History (2)

comment:1 Changed 14 years ago by danielk

Resolution: invalid
Status: newclosed

Does this happen with a recent version of ffmpeg? If so, you should report it directly to them. If not, we will need a backtrace with SVN head. See the TicketHowTo for a link to directions; we may need a 30 second snippet, 15 seconds before and 15 seconds after the problem occurs. If the problem is in ffmpeg proper, that project always requires the snippet for testing.

If the problem is in ffmpeg, reopen the ticket noting ffmpeg revision that it was fixed in. If the problem is exclusive to MythTV's ffmpeg reopen once you have the backtrace. Thanks :)

comment:2 Changed 14 years ago by ylee@…

I'll try to get to generating the backtraces and figuring out whether the current ffmpeg SVN still has the issue. In the meanwhile, for the record, the library versions I am using are ffmpeg 0.4.9-19_r7407 and libmpeg2_0-0.4.1-3 (both the latest available through ATrpms) on Fedora Core 6 x86_64 on a EM64T system.

Note: See TracTickets for help on using tickets.