Broken seeking in AVI files.

[rc57@…]

Mythvideo will not pause/seek videos from camcorder or internet I have tryed mythtranscode --buildindex --video --infile <filename> and Mythcommflag this fixes the seektables but the videos are corrupted to reproduce in mythvideo pause video (not a recording)try to seek forward/rewind

[robertm]

Please provide logs with -v playback both with and without a seektable built.

[anonymous]

Replying to rc57@…:

Mythvideo will not pause/seek videos from camcorder or internet I have tryed mythtranscode --buildindex --video --infile <filename> and Mythcommflag this fixes the seektables but the videos are corrupted to reproduce in mythvideo pause video (not a recording)try to seek forward/rewind

Added logs and looking in the dadtabase at table filemarkup i now have hunderds of lines Videofile.avi 80881 573731528 9 the numbers change on each line

[taylor.ralph@…]

rc57,

Without a seektable AVI files don't have the capability to do frame accurate seeking. All seeks will just send you to the previous/next key frame and be stuck there until you seek enough times that you hit another keyframe.

Current trunk will improve forward direction frame-by-frame seeking. When paused the first time you seek it will hit the keyframe and then subsequent forward frame seeks should work properly. I plan on further improvements for this.

I have no idea if building an seek table for an AVI works properly or not since I've never tried. The best thing to do is remux these videos into MKV with Avidemux2. The MKV supports proper seeking without the need of a seek table.

[taylor.ralph@…]

for avi container seek to previous frame byte position + 1 to make sure the key frame is decoded

[taylor.ralph@…]

improved version that uses previous end of frame position

[sphery]

I had changed the summary of the wrong ticket.

[tralph]

Closing ticket given we don't support seektables for AVI videos. The reason for this is that the byte position reported for a keyframe isn't exactly correct. It maybe an upstream ffmpeg bug or more likely just not possible with this container type. If the creator of this ticket would like more assistance then a new ticket needs to be created and a sample provided.