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

[John Pilkington]

On 23/08/14 04:06, 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

I just ran

mythutil --chanid 1019 --starttime 20140804105600 --getmarkup Inq.xml

on a shortish SD recording, which had, admittedly, been processed by 
mythDVBcut and so had a rebuilt seektable.  After a short header it 
shows only type="9" (byte) and type="33" (ms) marks.  I suspect the 
others may now be unused.