[mythtv-users] Keyframe identification in cutlist editor

[Michael T. Dean]

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.

Mike