Opened 14 years ago

Closed 13 years ago

#2353 closed defect (fixed)

SVN 11084: playback of edited MPEG4 recording consumes all memory and crashes on cutlist point

Reported by: oa@… Owned by: cpinkham
Priority: minor Milestone: unknown
Component: mythtv Version: head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

A recording made from a DVB source, auto-transcoded to MPEG4, cutlist edited and lossless transcoded to remove commercials halts playback on each cutpoint. The playback goes into a busy loop which allocates all memory and finally crashes to out of memory. MPlayer is able to play the same file, and so is mythfrontend if I manage to skip past the cut point with fast forward.

Attachments (2)

log.txt (56.1 KB) - added by oa@… 14 years ago.
log of playback (this over the network/nfs, but local playback exhibits same problem)
bt.txt (4.0 KB) - added by oa@… 14 years ago.
backtrace of the process (while suspended)

Download all attachments as: .zip

Change History (11)

Changed 14 years ago by oa@…

Attachment: log.txt added

log of playback (this over the network/nfs, but local playback exhibits same problem)

Changed 14 years ago by oa@…

Attachment: bt.txt added

backtrace of the process (while suspended)

comment:1 Changed 14 years ago by oa@…

experimenting with several files, it seems this problem might be related to aspect ratio changes in the original stream when entering the commercial break, or otherwise "unclean" frames in the stream at the transition point. However, I have not (yet) noticed these causing the described playback problem prior to the file being transcoded.

comment:2 Changed 14 years ago by Isaac Richards

I need a sample video to fix this.

comment:3 Changed 14 years ago by oa@…

Hmm. I've been trying to cut a manageable piece out of a recording that exhibits this, but mythtranscode crashes to a seg fault as well. I can put a full recording available if that is acceptable (around 770 megs), or try to catch some program during a commercial break, but the latter will take some more time.

comment:4 Changed 14 years ago by anonymous

fwiw, you can grab the full recording at http://htpc.home.fishpool.org/tmp/crash-at-0:14:36.nuv -- and like the name says, it crashes at 14 minutes, 36 seconds into the recording.

comment:5 Changed 14 years ago by oa@…

Please take a look at #2360 - while the symptoms are different, l have a feeling these are closely related

comment:6 Changed 14 years ago by cpinkham

Resolution: fixed
Status: newclosed

I believe this was fixed in [11314]. It sounds like the same exact symptoms especially the comment about this being related to aspect ratio changes.

comment:7 Changed 14 years ago by oa@…

Resolution: fixed
Status: closedreopened

I'm afraid my test clip still crashes at the same point. However, I applied [11314] to 0.20-fixes, so if there's some other changeset in the trunk that affects this, that might explain it. The patch applied cleanly, though.

comment:8 Changed 13 years ago by cpinkham

Owner: changed from Isaac Richards to cpinkham
Status: reopenednew

comment:9 Changed 13 years ago by cpinkham

Resolution: fixed
Status: newclosed

I believe this input file was corrupted by the bug in the transcoder that was fixed in [13647]. When I run this file through nuvscan, the info contained in the fileheader at the resolution change is corrupt. This is what is crashing the players now. I just checked and this fix was never copied over to the -fixes branch, so I have just merged [13647] into 0.20-fixes as [14548]. I'm going to close this ticket for now unless someone can reproduce this issue with current SVN trunk or -fixes version [14548].

Note: See TracTickets for help on using tickets.