Opened 16 years ago

Closed 15 years ago

#4527 closed defect (wontfix)

mythcommflag --rebuild of xvid avi segfaults and results in bad seek table.

Reported by: ebenblues@… Owned by: Isaac Richards
Priority: minor Milestone: unknown
Component: mythtv Version: head
Severity: medium Keywords: mythcommflag seek table rebuild avi
Cc: Ticket locked: no

Description

I transcoded an mpeg2 recording (recorded using ivtv) to an avi file using mencoder and xvid (see attached script). The script tries to use mythcommflag to rebuild the seek table:

mythcommflag -f file.avi --rebuild -v all

There are 2 problems: First, mythcommflag segfaults. Second, the output seems to indicate the file is recognized as mpeg4 and the seek table rebuild part completes before the segfault, but fastforward and rewind while watching the recording (via the "Watch Recordings" player) seems very broken. Fast forwarding at 3x speed advances the recording, but not smoothly and when I press play to resume the recording again, I see a partially painted frame for a few seconds, with parts of the frame retained from before the FF/RW, until it hits the next keyframe. Fast forwarding at any speed greater than 3x causes it to immediately jump to the end of the recording.

I've attached the script I'm using to transcode the mpeg files, a short sample avi file I have tried this on, and the output of the mythcommflag command. I have tried this both with 0.20.2 code and with a recent svn checkout (~2 weeks ago). I got the same results with both.

Attachments (2)

mpg2avi (2.1 KB) - added by ebenblues@… 16 years ago.
Script that converts mpeg2 file to avi and updates myth db.
mythcommflag.log (27.1 KB) - added by ebenblues@… 16 years ago.
mythcommflag verbose output

Download all attachments as: .zip

Change History (9)

Changed 16 years ago by ebenblues@…

Attachment: mpg2avi added

Script that converts mpeg2 file to avi and updates myth db.

Changed 16 years ago by ebenblues@…

Attachment: mythcommflag.log added

mythcommflag verbose output

comment:1 Changed 16 years ago by ebenblues@…

I didn't realize there was a limit to the size of attachments, so I couldn't attach the avi file. I can send it to someone's email if necessary.

comment:2 Changed 16 years ago by ebenblues@…

FYI, I brought this up on mythtv-users before submitting this ticket, and from the responses, others have experienced this same issue:

http://www.gossamer-threads.com/lists/mythtv/users/311748

comment:3 Changed 16 years ago by Joe Ripley <vitaminjoe@…>

The segfaults are probably caused by your version of Qt. This is most likely the same issue discussed here:

http://www.gossamer-threads.com/lists/mythtv/users/304815#304815

From the log, it appears that mythcommflag is finishing and then segfaults at the very end (similar to the mythfilldatabase segfaults discussed in the quoted thread

-- Joe Ripley vitaminjoe@…

comment:4 Changed 16 years ago by kepesk@…

I am also seeing the exact same fast forward issues when playing back xvid files on a current svn checkout. However, I am not attempting to rebuild the seek tables before playing back the file, so the mythcommflag segfault and the fast forward issues may be two separate issues. I do have some more insight into the fast forward issue; it appears that fast forwarding an xvid file results in advancment in the file much farther than is indicated by the OSD. Using the fast forward seems to make the playback advance much faster than is intended, which is why the playback ends when fast forwarding faster than 3x for more than a couple of seconds; it reaches the end of the file much quicker than is reasonable and far sooner than the OSD indicates. I hope this helps!

comment:5 in reply to:  4 Changed 16 years ago by Joe Ripley <vitaminjoe@…>

Replying to kepesk@gmail.com:

I am also seeing the exact same fast forward issues when playing back xvid files on a current svn checkout. However, I am not attempting to rebuild the seek tables before playing back the file, so the mythcommflag segfault and the fast forward issues may be two separate issues.

You must rebuild the seek tables after any modification to the source video. If you don't, you'll get seeking/fast forward/rewind problems. Myth depends on an accurate seek table to move around in a video file. When you transcode a video from MPEG2 to XVID, it gets considerably smaller (depending on bitrate). Seeking based on the old MPEG2 seek table will only work until you pass the end of the XVID (and with inaccurate OSD info). So, a 2.2 GB MPEG2 transcoded to 700 MB will only seek properly UP TO the 700 MB mark... Myth will still think there's 1.5 GB of material to seek through, and since there isn't, it will fail.

The FF/REW problem is real in that the video output is as the ticket description indicates: artifacts, partially painted frames, doesn't clear up until the next keyframe is hit. I see this with h.264 videos as well. Seeking works, it's just not pretty.

-- Joe Ripley vitaminjoe@…

comment:6 Changed 15 years ago by laga

Status: newinfoneeded_new

Does this still happen in trunk?

comment:7 Changed 15 years ago by robertm

Resolution: wontfix
Status: infoneeded_newclosed

Info not provided in five weeks, closing worksforme. Tested above procedure with three xvid AVIs w/o segfaults.

Note: See TracTickets for help on using tickets.