Modify

Ticket #7849 (closed Bug Report - General: Won't Fix)

Opened 2 years ago

Last modified 4 months ago

Broken seeking in AVI files.

Reported by: rc57@… Owned by: tralph
Priority: minor Milestone: unknown
Component: MythTV - Video Playback Version: 0.22-fixes
Severity: medium Keywords:
Cc: Ticket locked: no

Description

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

Attachments

Noseektable.txt (139.8 KB) - added by anonymous 2 years ago.
withseektable.txt (65.1 KB) - added by anonymous 2 years ago.
t7849_mythtv_avi_seektable_fix.diff (1.3 KB) - added by taylor.ralph@… 2 years ago.
for avi container seek to previous frame byte position + 1 to make sure the key frame is decoded
t7849_mythtv_avi_seektable_fix_v2.diff (1.5 KB) - added by taylor.ralph@… 2 years ago.
improved version that uses previous end of frame position

Change History

comment:1 Changed 2 years ago by robertm

  • Priority changed from major to minor
  • Status changed from new to infoneeded_new
  • Component changed from Plugin - MythVideo to MythTV - Video Playback

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

Changed 2 years ago by anonymous

Changed 2 years ago by anonymous

comment:2 in reply to: ↑ description Changed 2 years ago by 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

comment:3 Changed 2 years ago by robertm

  • Keywords mythvideo removed
  • Status changed from infoneeded_new to new

comment:4 Changed 2 years ago by 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.

Changed 2 years ago by taylor.ralph@…

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

Changed 2 years ago by taylor.ralph@…

improved version that uses previous end of frame position

comment:5 Changed 2 years ago by mdean

  • Summary changed from seektable to Seektable built during recording is broken; fixed by rebuilding seektable

comment:6 Changed 2 years ago by mdean

  • Summary changed from Seektable built during recording is broken; fixed by rebuilding seektable to Broken seeking in AVI files.

I had changed the summary of the wrong ticket.

comment:7 Changed 22 months ago by robertm

  • Owner changed from awithers to tralph
  • Status changed from new to assigned

comment:8 Changed 10 months ago by tralph

  • Owner tralph deleted
  • Status changed from assigned to new

comment:9 Changed 10 months ago by beirdo

  • Type changed from defect to Bug Report - General

comment:10 Changed 6 months ago by markk

  • Owner set to tralph
  • Status changed from new to assigned

comment:11 Changed 4 months ago by tralph

  • Status changed from assigned to closed
  • Resolution set to Won't Fix

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.

View

Add a comment

Modify Ticket

Action
as closed
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.