[mythtv-users] Keyframe identification in cutlist editor

[John Pilkington]

No doubt I should get out more, and it's probably not worth my looking 
at this further while I'm still running 0.24-fixes, but I think it's 
worth reporting more inconsistencies.  Input is DVB-T in the UK.

My mythcutprojectx logs show frame numbers for cut-in in the 
demultiplexed video output from ProjectX:

-> cut-in @ GOP# 1672 / new vframe 13462 / new Timecode 00:08:58.480 
(299665420)

Video and audio streams are then synced and passed through mplex, and a 
new seektable is generated by  mythtranscode --mpeg2 --buildindex.  The 
sync process may make small adjustments to the frame numbers.

When the new file is viewed in the frontend editor the first frame after 
a cut does not coincide exactly with the vframe number above and it is 
not identified as a keyframe.  Typically the nearest keyframe is about 
two frames after the new scene appears.  This is about the same as I 
usually see for unprocessed recordings, in which the keyframe sequence 
is controlled by the broadcaster.

I then tried the alternative way of recreating the seektable, using 
mythcommflag --rebuild on the processed recording.  This gave a larger 
offset between editor-identified keyframes and the scene change.

I haven't done this often, so I can't say how typical this is, but it 
seems that mythcommflag and mythtranscode don't necessarily give 
identical seektables for mpeg2 recordings.  I don't suppose the 
difference is important for their main use in supporting forward or 
backward skips.   I haven't looked at the codes yet.  I may do that but 
experience suggests that not much enlightenment will result.

John P