Opened 10 years ago

Closed 9 years ago

#10300 closed Bug Report - General (fixed)

Seek problems with Handbrake 0.9.5 produced m4v files

Reported by: Jason Gillis <gillisj@…> Owned by: tralph
Priority: minor Milestone: 0.25
Component: MythTV - Video Playback Version: 0.24-fixes
Severity: medium Keywords:
Cc: Ticket locked: no


I've been noticing that myth has recently started to have problems with seeking in m4v files produced by Handbrake (I'm using 0.9.5 for OSX currently, happens with a recent nightly build of Handbrake, also). This was raised on the users list here:

The basic symptoms are that playback appears fine, without any A/V sync issues and no noticeable problems until seeking occurs (usually in response to "What did he say?"). When seeking back, myth skips back to much earlier in the m4v file than expected with a 5 second skip back. It can be as much as 10 minutes.

I've noticed that the current time position display in the OSD seems to advance more slowly than real-time. When skipping back, myth seems to correctly skip back to 5 seconds before what it thinks is the current time position in the file. In the attached file, I skipped back right before the end of the log file. Myth had been playing for about 52 minutes. Just prior to skipping back, the time display on the OSD noted 39 minutes and some seconds. Skipping back went back to the correct position for that time in the file, so the amount skipped back was in excess of 10 minutes.

Re-encoding the source DVD to MKV format using handbrake yields a file that does not show this problem. Choosing different encoding options in Handbrake for m4v output don't change the incorrect seek behavior.

Attached are output of the myth version, a log file produced using -v playback,timestamp,extra (per request from Taylor Ralph) and the video info for the file (both mythffmpeg and mediainfo).

Please let me know what additional information I can provide.

Attachments (3)

videoinfo-mediainfo.txt (5.3 KB) - added by Jason Gillis <gillisj+mythtv@…> 10 years ago.
Video info from media info (on Windows)
videoinfo-mythffmpeg.txt (3.3 KB) - added by Jason Gillis <gillisj+mythtv@…> 10 years ago.
Video info (mythffmpeg)
mythversion.txt (746 bytes) - added by Jason Gillis <gillisj+mythtv@…> 10 years ago.
mythfrontend --version output

Download all attachments as: .zip

Change History (7)

Changed 10 years ago by Jason Gillis <gillisj+mythtv@…>

Attachment: videoinfo-mediainfo.txt added

Video info from media info (on Windows)

Changed 10 years ago by Jason Gillis <gillisj+mythtv@…>

Attachment: videoinfo-mythffmpeg.txt added

Video info (mythffmpeg)

Changed 10 years ago by Jason Gillis <gillisj+mythtv@…>

Attachment: mythversion.txt added

mythfrontend --version output

comment:1 Changed 10 years ago by Jason Gillis <gillisj@…>

OK, my log file is too big, so here's a link to it in my Dropbox:

comment:2 Changed 10 years ago by markk

Owner: markk deleted
Status: newassigned

comment:3 Changed 9 years ago by tralph

Owner: set to tralph
Status: assignedaccepted

comment:4 Changed 9 years ago by Github

Milestone: unknown0.25
Resolution: fixed
Status: acceptedclosed

avformatdecoder: improve fps detection in normalized_fps()

This should fix issues with mov style containers by using the avg_frame_rate which is set by the demuxer.

NOTE: Using estimated_fps seems to always be accurate for everything except matroska and mov. It appears that ffmpeg takes into account the codec and container fps when generating estimated_fps. Also, XBMC uses estimated_fps for everything except matroska. We should probably do the same.

Fixes #10300.

Branch: master Changeset: 6c22eda37519a3da50558e468ce0a76e770b9399

Note: See TracTickets for help on using tickets.