[mythtv-users] keyframes in cut list editor off by one frame

[John Finlay]

On 8/22/2014 8:06 PM, Tony Sauri wrote:
> On 23/08/14 11:13, Mark Perkins wrote:
>> Just to be clear *I think* there is a mismatch of 1 between the frame viewed in the cutlist editor and the frame number. Whether that is because the wrong frame is displayed on the screen or the wrong frame number is displayed or something else I don't know. So it's not just the keyframes affected, every frame / frame number is out by 1.
> I have been following this discussion because I have been investigating
> this very issue.
>
> The other day I use ImageMagick to create 15000 images with a plain
> black background bearing an ascending integer starting from 000001 to
> 015000.
>
> I then used FFMPEG/AVCONV to assemble these images into a mpeg2 video
> stream. Saved the resulting file into my videos library.
>
> When I play this file and start the cut editor I can now confirm that
> the reported frame numbers _ARE_ correct  (ie editor frame number 1
> agrees with the number on the image).
>
> However the time stamp shown by the editor for frame 1 is 00:00.040
> which would be the correct time after the frame is shown.
> If using AVCONV/FFMPEG to edit the file you would use -ss 0.000 to start
> at frame 1.
>
> Another point is that the the myth cut editor when set to jump to the
> next keyframe goes 1 ...16 ... 31   46 (every 15 frames
> When I load the file into avidemux it says the frame bearing the frame
> number 000001 is frame 0 and advancing to keyframes shows 0 ... 15 ...
> 30 etc
>
> Leaves me wondering if this is all a case of the first frame of a stream
> is frame 0 or frame 1?
>
> Earlier in the discussion  the 1 frame discrepancy between the
> recordedseek table and the cutlist-editor initially troubled me but then
> I read the wiki documentation for the
> recordrdseek table at http://www.mythtv.org/wiki/Recordedseek_table
>   which says :
>
> 	       TYPE     MARK-TYPE	
> 		6 	MARK_GOP_START
> 		7 	MARK_KEYFRAME
> 		8 	MARK_SCENE_CHANGE
> 		9 	MARK_GOP_BYFRAME
>
> If the records in the recordedseek table were pointing to Keyframes then
> they would/should be Type 7's whereas what I (and you) see are type 9's.
>   Now I have never been able to find a definition of GOP_BY_FRAME but I
> am coming to the belief that it marks the last frame in  a Group of
> Pictures.  I would love to have some clarity around exactly what the
> GOP_BYFRAME does represent.
>
> Regards
>
> Tony Sauri
>
>

My experience with MPEG2 OTA files indicates that one problem is the 
difference in numbering the frames in the file between the cutlist 
editor and other programs like mythffmpeg and mythtranscode. It seems 
that the cutlist editor numbers frames from 1 while mythffmpeg and 
mythtranscode number from 0. Therefore when using the cutlist editor 
frame values with these programs you do not get cuts at the frame number 
you expect. When I examine the markup for a file I see that the type 9 
seek entries have the same frame number as the I keyframes as output by 
mythffprobe when looking at the packet stream and both are one less than 
the frame numbers used by the cutlist editor. When I use mythffmpeg 
(which only cuts on keyframe boundaries) to cut sections out of a file I 
have to subtract one from each of the cutlist numbers to get a perfect 
cut at the keyframes.

The second problem is with mythtranscode which tries to do a frame 
perfect cut at any frame. As I understand it when it does this it 
decodes every frame and rearranges them into presentation order before 
it starts counting. Depending on the composition of  I, P and B frames 
in the file the numbering of keyframes can change so that a keyframe can 
have a number in mythtranscode which varies as less than, the same as or 
greater than the cutlist keyframe number. For example in some cases 
where the cut contains B frames the keyframe can have a frame number 
that is plus two compared to its packet stream number which leaves it 
with a frame number one larger than the cutlist number. This makes it 
difficult to get an exact cut using mythtranscode.

John