[mythtv-commits] Ticket #11420: Some .avi files fail to resume from bookmarks

MythTV noreply at mythtv.org
Sat Feb 23 16:08:10 UTC 2013


#11420: Some .avi files fail to resume from bookmarks
---------------------------------+-----------------------------------------
 Reporter:  David Hill <myth@…>  |           Type:  Patch - Bug Fix
   Status:  new                  |       Priority:  minor
Milestone:  unknown              |      Component:  MythTV - Video Playback
  Version:  Unspecified          |       Severity:  medium
 Keywords:                       |  Ticket locked:  0
---------------------------------+-----------------------------------------
 For some .avi files in my video collection, if I attempt to resume from a
 bookmark, the system hangs for 2-3 minutes, then fails to start the video.
 I narrowed the problem down to the AvDecoder::DoFastForward() routine
 attemping to seek to a very large value which took 2.5 minutes before it
 hit the decoding error.  When run with '-v playback', I saw the following
 entries in the log covering the time it was hung:

 2013-02-22 21:46:36.641201 I  AFD: SeekReset(-97191818680052, 1003750634,
 do flush, do discard)
 2013-02-22 21:46:36.641228 I  AFD: SeekReset() flushing
 2013-02-22 21:49:03.111325 E  decoding error
                         eno: Unknown error 541478725 (541478725)


 After inserting some log messages, I noticed that st->cur_dts has a bogus
 value before any frames have been played and this was then being used in
 the scaling code to adjust the dts values.

 2013-02-22 21:46:36.641105 I  AFD: DoFastForward cur_dts
 9223090561878065151, ic->start_time 0, adjust_cur_dts 9223090561878065151
 2013-02-22 21:46:36.641133 I  AFD: DoFastForward adj_cur_dts
 9223090561878065151, adj_seek_dts 11766, max_dts -1, newts
 -3242967031675738028
 2013-02-22 21:46:36.641157 I  AFD: DoFastForward lastKey -97191818680052
 framesPlayed -97191818680052, normal frames 1003750634
 2013-02-22 21:46:36.641177 I  AFD: DoFastForward: About to SeekReset()
 lastKey -97191818680052, normalframes 1003750634

 However, after the first frame is played, st->cur_dts seems to either hold
 the appropriate timestamp value or the AV_NOPTS_VALUE.

 Here is the ffmpeg info on one of the effected videos:
 Input #0, avi, from '/storage/videos/DVDs/The_Addams_Family.avi':
   Metadata:
     encoder         : Lavf52.22.1
   Duration: 01:39:37.29, start: 0.000000, bitrate: 1274 kb/s
     Stream #0.0: Video: mpeg4, yuv420p, 640x360, PAR 1:1 DAR 16:9, 29.97
 tbr, 29.97 tbn, 29.97 tbc
     Stream #0.1: Audio: mp3, 48000 Hz, stereo, s16, 64 kb/s

 Please let me know if you need any further information.

 The patch forces it through the "No DTS Hack" codepath when framesPlayed
 == 0 and this seems to resolve the issue.

-- 
Ticket URL: <http://code.mythtv.org/trac/ticket/11420>
MythTV <http://code.mythtv.org/trac>
MythTV Media Center


More information about the mythtv-commits mailing list