Cutlist editor does not identify keyframes reliably

[J.Pilk@…]

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

[stichnot]

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

[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.

[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.

[stichnot]

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.

[stichnot]

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.

[Github]

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