Opened 11 years ago

Closed 11 years ago

#11144 closed Bug Report - General (Fixed)

mythcommflag --rebuild and --video creates invalid keyframe "mark" values

Reported by: r.d.vaughan@… Owned by: Jim Stichnoth
Priority: minor Milestone: 0.25.4
Component: MythTV - Mythcommflag Version: 0.25-fixes
Severity: medium Keywords: keyframe mythcommflag rebuild
Cc: Ticket locked: no

Description

In at least MythTV v0.25-fixes, mythcommflag --rebuild and --video creates "mark" values in the recordedseek table that are not keyframes for HDPVR (h.264) recordings. The mark values bear no resemblance to the values which were inserted during the original recording.

See: http://pastebin.com/V2tG3jup

Change History (6)

comment:1 Changed 11 years ago by J.Pilk@…

This ticket is a close relative of #10584. For UK dvb-t, and for a dvb-t2 HD recording from Channel 4 HD, the keyframe lists appeared to be the same after the first few keyframes. The shift in origin would affect the computed location of a cut in the output file unless mythcommflag --rebuild was run before generating a cutlist with the the editor. I'm afraid I haven't looked at this more recently.

comment:2 Changed 11 years ago by blm-ubunet@…

My recordings are from dvb-t & are AVC with intra-refresh (no IDR). I observe the seektable offset (from binary byte offset cutting etc) to be related to the difference in audio pkt PTS & video pkt PTS. Is MythTV using the audio PTS as the timecode?

Graphing the first hundred or so (mark,offset) from (recordedseek) as incremental diffs shows the first 2-3 to be abnormal.

Confirming what the keyframes are (& where they are) is problematic. ffprobe reports no keyframes. Avidemux shows no keyframes but can count/decode/display frames.

comment:3 in reply to:  2 ; Changed 11 years ago by blm-ubunet@…

Replying to blm-ubunet@…:

Using ffprobe -show_frames etc..can confirm that the mythtv seektable "mark" are "coded_picture_number" values & match those from ffprobe.

Calculating timecode cuts using myth seektable & framerate & then using ffmpeg -segment <timecode> etc..results in a file with time offsets that are not dissimilar from the audio-video PTS offset.

comment:4 in reply to:  3 Changed 11 years ago by blm-ubunet@…

Replying to blm-ubunet@…:

Replying to blm-ubunet@…:

So the myth seektable values for (mark,offset) match exactly with the ffprobe reporting.

Is the problem with ffmpeg ?

comment:5 Changed 11 years ago by Jim Stichnoth

Milestone: unknown0.25.4
Owner: changed from cpinkham to Jim Stichnoth
Status: newaccepted

comment:6 Changed 11 years ago by Jim Stichnoth

Resolution: Fixed
Status: acceptedclosed

This should be fixed by 590f161b1d5ff8c7e08b0beae480ece7a185d3ab (master), 28846f87db59efa28ce20c9309089a49520227bb (fixes/0.26), and 87a0eef9cbff7573298532626d46f727db8c9f5d (fixes/0.25).

Note: there are still some discrepancies in frame numbering between the recorder, mythcommflag, and raw ffmpeg.

Note: See TracTickets for help on using tickets.