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: | 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.
Change History (6)
comment:1 Changed 11 years ago by
comment:2 follow-up: 3 Changed 11 years ago by
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 follow-up: 4 Changed 11 years ago by
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 Changed 11 years ago by
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
Milestone: | unknown → 0.25.4 |
---|---|
Owner: | changed from cpinkham to Jim Stichnoth |
Status: | new → accepted |
comment:6 Changed 11 years ago by
Resolution: | → Fixed |
---|---|
Status: | accepted → closed |
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.
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.