Opened 7 years ago

Closed 7 years ago

#10389 closed Bug Report - General (fixed)

Cutlist editor does not identify keyframes reliably

Reported by: J.Pilk@… Owned by: Jim Stichnoth
Priority: minor Milestone: 0.25
Component: MythTV - General Version: 0.24-fixes
Severity: medium Keywords: cutlist editor keyframe
Cc: Ticket locked: no

Description

In keyframe-stepping mode the sequence of frames selected by the cutlist editor often depends on the stepping direction. Stepping forward usually finds fewer keyframes than stepping back.

This has been aired on the user list, with most of the discussion about the perceived (or not) benefits of cutting at keyframes. I'm creating this Ticket as a reminder that the inconsistent behaviour exists.

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

Change History (7)

comment:1 Changed 7 years ago by Jim Stichnoth

Status: newinfoneeded_new

John, can you upload somewhere a 50-100MB excerpt of a recording that has the problem, and provide a link to it? Use something like this to create the sample:

dd if=/path/to/original.mpg of=sample.mpg bs=1M count=100

comment:2 Changed 7 years ago by J.Pilk@…

Hi: I'm new to this. After several attempts that looked as if they were working but failed, there's a 50 MB sample at http://www.mediafire.com/?d4zfkyy51dyq1x3

It was the only raw recording I had when I started, and this is cut from the middle of the programme. Some sections step forward and back consistently but the ticket behaviour shows elsewhere, often when the camera changes. Channel was BBC2 SD.

If this works and is helpful I can try uploading an HD sample.

comment:3 Changed 7 years ago by J.Pilk@…

I suspect that this sample from mid-programme is less "busy" than where I usually do cuts. After reinserting the sample as a recording and regenerating a seektable I find examples at frame 247 and frame 1000. Both lie between sections with regularly spaced (24) keyframes.

comment:4 Changed 7 years ago by Jim Stichnoth

Resolution: Fixed
Status: infoneeded_newclosed

This appears to be fixed in master (unfortunately I don't have a 0.24 setup to test on).

The only issue I see is that in keyframe-stepping mode, the BIGJUMPFWD key jumps forward 5 keyframes (instead of 10 as I would expect) and BIGJUMPREW jumps back 6 keyframes. Otherwise, all single-keyframe seeks, both forward and backward, behave consistently.

BTW, you can drop a file into the MythVideo? area and generate a seek table:

mythcommflag --rebuild --video Ticket10389_50.mpg

Given the upcoming 0.25 release, I'm closing this as Fixed. Please reopen if you see the problem in master or (eventually) 0.25.

comment:5 Changed 7 years ago by Jim Stichnoth

Resolution: Fixed
Status: closednew

On further investigation, I do see the problem in master.

Keyframes at frames 214,223,247. Stepping left from 247 gets to 223, and left from 223 gets to 214. However, stepping right from 223 gets to 247.

Keyframes at frames 967, 976, 1000. Stepping left from 1000 gets to 976, and left from 976 gets to 967. However, stepping right from 967 gets to 1000.

comment:6 Changed 7 years ago by Jim Stichnoth

Milestone: unknown0.25
Owner: set to Jim Stichnoth
Status: newaccepted

comment:7 Changed 7 years ago by Github

Resolution: fixed
Status: acceptedclosed

Program editor: don't seek too far when stepping to the next keyframe.

Fixes #10389. When stepping to the next keyframe to the right, some old code causes it to skip over the next keyframe if it is too close. This code seems unnecessary, but it is left there for now (commented out) in case a valid reason is discovered.

Branch: master Changeset: a6b1e3a72ab80b05b37d015aefaec8df2c14c817

Note: See TracTickets for help on using tickets.