[mythtv-users] Keyframe identification in cutlist editor
John Pilkington
J.Pilk at tesco.net
Sat Mar 10 12:44:20 UTC 2012
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
More information about the mythtv-users
mailing list