[mythtv-users] Keyframe identification in cutlist editor

[John Pilkington]

On 21/02/12 20:49, Michael T. Dean wrote:
> On 02/21/2012 03:16 PM, John Pilkington wrote:
>> On 21/02/12 18:34, Thomas Boehm wrote:
>>> John Veness wrote:
>>>> Personally I've never skipped forward or back by keyframe either, and
>>>> for me it's just an annoying step to get past (with the up/down arrows)
>>>> between Frame and 0.5 Seconds, both of which are useful. It would be
>>>> interesting to see if anyone really used Keyframe when editing, and if
>>>> not, just remove it from the list.
>>> I use it and it looks like MPEG-2 can only be cut on a keyframe, correct
>>> me if I'm wrong. I tried to cut on non-keyframes in the past and AFAIR
>>> there where always more frames in the show after cutting or less.
>>>
>>> I just tried it and cut 1500 frames from a show. The result after
>>> transcoding (ProjectX + HandBrakeCLI) had only 1462 frames.
>>>
>>> It looks like MythTV automatically sets the cut point to the preceding
>>> keyframe. I double checked my next trial before transcoding and the cut
>>> point was moved by MythTV when I set it to a non-keyframe...
>> It must surely depend on the tools being used.  ProjectX as used in
>> mythcutprojectx often reports that it is 'dropping useless B-frames' -
>> and as I said before, I have rarely used keyframe positions within the
>> editor -  but I'm subjectively convinced that it isn't as coarse-grained
>> as just cutting at keyframes.  Similarly I'm sure that more accurate
>> cutting is possible;  nice as that would be, I'm just not sure it's
>> worth pursuing in the general ad-cutting context.
>>
>> Time I looked at the rapidly evolving web-based editor, perhaps?  A week
>> ago I thought I needed a HowTo :-)
>
> FWIW, MythTV's mythtranscode has a "lossless" transcoding mechanism for
> MPEG-2, only, that will transcode by cutting out sections of the video.
> Within those sections, any full GOPs (where a GOP always begins with an
> "I-frame" (intra-coded picture, a.k.a. key frame)) are removed.  Any
> partial GOPs are re-encoded, and frames (including I-frames) added, as
> necessary to ensure all frames have required reference frames (or no
> longer need reference frames).  This allows mythtranscode to perform
> lossless transcoding at better-than-keyframe resolution
> (frame-accurate), by only transcoding around the actual cuts, and only
> when necessary.
>
> Note that mythtranscode cannot do this for MPEG-4 or RTJPEG (in NUV) or
> for H.264.  And, if you end up with an NUV file, you're not using
> lossless transcoder (but the lossy transcoding can also transcode with
> frame-accurate cuts).
>
> Note, also, that mythtranscode hasn't gotten much TLC, lately, and has
> some issues with some recordings (especially ones with changing audio
> channels or frame rates or ...--things that have become more common with
> the transition to digital broadcast).  That said, mythtranscode's
> lossless transcoding is, IMHO, the only worthwhile part of mythtranscode
> (and would be a great area for a motivated user to spend some time
> working).  The lossy transcode isn't worthwhile because a) it puts video
> into an NUV container, which isn't usable by much of anything; and b)
> it's processor intensive, and expensive due to increased power usage,
> even when compared to the cost of HDD space, which means that the only
> real reason to do lossy transcoding is to allow playback on
> "format-constrained" devices (cell phones, tablets, ...), and not for
> saving storage space.
>

It ought to be possible to work around the mythtranscode -m -l failures 
with some recordings, and so get frame-accurate editing, by cleaning 
them up with ProjectX first, but ISTR trying this some time ago without 
great success.  And of course it takes longer, and you might actually 
want the datastreams that have been cleaned away.  And, like 
mythtranscode -m -l, ProjectX doesn't work for h.264....

But to return to the original topic; it would be great if Jim could 
Fix-It ((c) BBC circa 1970, IIRC)

John P