Modify
Warning Please read the Ticket HowTo before creating or commenting on a ticket. Failure to do so may cause your ticket to be rejected or result in a slower response.

Opened 19 months ago

Closed 16 months ago

#11144 closed Bug Report - General (Fixed)

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

Reported by: r.d.vaughan@… Owned by: stichnot
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

Attachments (0)

Change History (6)

comment:1 Changed 19 months 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 follow-up: Changed 18 months 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 ; follow-up: Changed 18 months 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 18 months 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 16 months ago by stichnot

  • Milestone changed from unknown to 0.25.4
  • Owner changed from cpinkham to stichnot
  • Status changed from new to accepted

comment:6 Changed 16 months ago by stichnot

  • Resolution set to Fixed
  • Status changed from accepted to 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.

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'new'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.