Opened 11 years ago
Closed 4 years ago
#12010 closed Bug Report - General (Unverified)
mythcommflag --rebuild does not re-create good seektables with h264 recordings
| Reported by: | Owned by: | Peter Bennett | |
|---|---|---|---|
| Priority: | minor | Milestone: | unknown |
| Component: | MythTV - Video Decoding | Version: | Master Head |
| Severity: | medium | Keywords: | mythcommflag --rebuild h264 |
| Cc: | Ticket locked: | no |
Description
This looks like a re-run of #11435 and #6243. Initial report here, quoted below.
http://www.gossamer-threads.com/lists/mythtv/users/561003#561003
I have just found that for recordings from DVB-T2 FreeviewHD in the UK, (h264), a listing of the markup data generated after mythcommflag --rebuild contains only a small subset of the lines in a similar listing made immediately after recording.
In the 'original' table, keyframe separation is typically around 24 frames. In the 'rebuilt' table the spacing is variable, sometimes in the hundreds of frames. Points listed there are also in the original table.
hexdump shows that all keyframes in the original list for this recording begin 47 40 65 3x, and to me look genuine. The problem does not affect DVB-T SD recordings, which are mpeg2 format.
In my tests I have usually been working with recordings having seektables that have been rebuilt, often several times. This may explain why editing has sometimes been difficult.
mythutil --chanid 1102 --starttime 20140109182600 --getmarkup Haworth_orig.xml mythcommflag --rebuild --chanid 1102 --starttime 20140109182600 mythutil --chanid 1102 --starttime 20140109182600 --getmarkup Haworth_rebuilt.xml
ls -l Haw* -rw-rw-r--. 1 john john 290708 Jan 9 19:13 Haworth_orig.xml -rw-rw-r--. 1 john john 73286 Jan 9 19:16 Haworth_rebuilt.xml
Attachments (3)
Change History (28)
Changed 11 years ago by
| Attachment: | Simp_rebuilt.xml added |
|---|
Changed 11 years ago by
| Attachment: | Simp_orig.xml added |
|---|
comment:1 Changed 11 years ago by
comment:2 Changed 11 years ago by
| Component: | MythTV - General → MythTV - Video Decoding |
|---|---|
| Owner: | set to Jim Stichnoth |
| Status: | new → accepted |
The situation here is that the recorder has captured keyframes as a combination of IDR keyframes and non-IDR I-frames, but mythcommflag is only registering IDR keyframes.
The fundamental problem is that the particular recorder decides whether non-IDR I-frames are allowed to act as keyframes, but the recorder leaves no clues in the recording itself about which recorder was used. This leaves mythcommflag to guess whether or not to register a keyframe when it sees a non-IDR I-frame.
The default behavior is to assume only IDR keyframes, but then you find e.g. DVB-S transmissions that completely lack IDR keyframes, hence the logic in 802e32ba4dc8852da56db170893e95cbc28637e3 that rewinds and retries with the more lenient setting when it doesn't find an IDR keyframe within the first 1000 or so frames.
Unless ffmpeg can somehow figure this out for us automatically, the only solution I can think of is to add an extra flag to "mythcommflag --rebuild" that allows the user to manually override the IDR-vs-I-frame decision.
comment:3 Changed 11 years ago by
Thanks, Jim, for the explanation. An extra flag, or a different option name, would be fine for me, and the default could be left as it is so that anyone who doesn't have problems at present wouldn't be affected. I suppose that at a particular site the setting might be associated with chanid via a config table - but I doubt that that would be worth the complication.
comment:4 Changed 11 years ago by
I rebuilt 0.27-fixes today with the patch posted here:
http://www.gossamer-threads.com/lists/mythtv/users/562035#562035
With a single short test recording (3436 frames) the before-and-after getmarkup files are almost identical, with just one of the original keyframes not found. hexdump looks as if it is real. Editor responsiveness is fine. Keyframe numbers displayed by the editor are +1 frame relative to those listed. Stepping forward by single frames, a sudden scene change occurs when the editor frame-number coincides with the 'missed' keyframe, but this isn't true for the 'Braz' clip that I posted in the thread above, in which 2 of the original keyframes were missed.
On this showing I would be happy to see this patch committed. Thank you!
comment:5 Changed 11 years ago by
AFAIU The patch from http://www.gossamer-threads.com/lists/mythtv/users/562035#562035 has a mistake.
- if (!usingIframes &&
- (GetEof() != kEofStateNone || (frames > 1000 && frames < 1100)) &&
+ if (usingIframes &&
+ (GetEof() != kEofStateNone || (frames > 100 && frames < 1100)) &&
!decoder->HasPositionMap())
The test "frames >100" should have just been left as original code "frames > 1000"
Sorry.
comment:6 Changed 10 years ago by
I have v0.28-pre-2255-ge3d17b6 built with a minimally-updated version of this patch. In a test recording from BBC TWO HD DVB-T, duration almost 42 minutes, the original seektable includes only 7 frames that are not in the rebuild. Each getmarkup file is 288 kB. I haven't tested a recent build without the patch, but I suppose it would have the original problem. Is a commit still not possible?
Changed 10 years ago by
| Attachment: | mythtv-master-seektable.patch added |
|---|
comment:7 Changed 10 years ago by
For convenience I have attached my update for master of the original patch by 'blm-ubunet'. It applies OK for me during rpmbuild although some chunks get 1-line shift.
comment:8 Changed 10 years ago by
Mythcommflag v0.28-pre-2291-gd97aeef
Running mythcommflag --rebuild results in an empty recordedseek table for that recording. Recordings are H.264 HD recordings from HD-PVR. Would this issue apply, and has this patch been applied to the 0.28 branch?
comment:9 Changed 10 years ago by
When I opened this ticket, the problem was that mythcommflag --rebuild in fixes did not find most of the original keyframes. Recently I've been running master with the patch attached earlier; I make few HD recordings, but it has seemed to do the job.
I now find that in current builds of 0.27-fixes almost all of the original keyframes are found, at the same byte-offsets, but the frame-numbers and timestamps drift gradually away from their original values; over a 1-hour recording the rebuilt table shows 48 fewer frames and a duration 1920 ms less.
wc -l *.xml shows 6487 lines originally, 6478 after the rebuild. It looks as if keyframe detection has been fixed somehow, but frame counting is - literally - adrift.
This was a DVB-T2 recording from BBC FOUR HD
comment:10 Changed 10 years ago by
It seemed worth running a similar test with the patched current-master. With a 4-minute recording, "diff XX_orig.xml XX_rebuilt.xml" showed that *that* rebuild omitted only the 0 ms timestamp and was otherwise the same as the original.
For me, this is better than I saw with current-fixes, but current-fixes without the frame-count-drift would be OK.
comment:11 Changed 10 years ago by
Another datapoint, this time with today's unpatched build of master for ubuntu trusty, [v0.28-pre-2593-gea542a9]. Recording DVB-T2 cbbc HD, wc -l gives 4707 for original, 4700 for rebuild. It's very similar to the results for unpatched -fixes at Comment 9; byte offsets are identical, rebuilt frame count this time is 17 greater than the original.
comment:12 Changed 7 years ago by
| Owner: | changed from Jim Stichnoth to Peter Bennett |
|---|---|
| Status: | accepted → assigned |
comment:13 Changed 7 years ago by
| Version: | 0.27-fixes → Master Head |
|---|
comment:14 Changed 7 years ago by
I have a similar issue with building seektables for h264 video, that has irked me for some time. I am looking into that related problem. See https://lists.gt.net/mythtv/users/536443#536443.
comment:15 Changed 7 years ago by
Do you have a sample recording avail ? None of my international collection or broadcast H264 causes any problems with incorrect keyframe/seektable generation. But I have some H264Parser patches dating back some years now.
comment:16 Changed 7 years ago by
The problem was with h264 mkv files, created using handbrake from recordings. See https://lists.gt.net/mythtv/dev/614921
comment:17 Changed 7 years ago by
Peter: You suggested this might be associated with #13242, and asked for a sample file. I'll try to send something useful. Regenerating a seektable from my latest raw sample, and some others, is done at around 120 fps, while I usually see something much faster. It's faster without the extra streams, too. I find that repeated rebuilds are consistent and believe the recorder may miss a few.
I tried vidcutter a few weeks ago and found an ffprobe keyframe command line, which I now see was being used with mkv, that I hadn't seen before. It's here, but I haven't tried timing it:
comment:18 Changed 7 years ago by
http://www.mediafire.com/file/34rba3pe4tzutcx/21728_20180310185800.ts
64 MB Clip from Channel 5 HD DVB-T2
comment:19 Changed 7 years ago by
There seems to be another problem with h264 seektables: although raw and rebuilt seektables are now near-identical there is a 7(ish)-frame mismatch between major scene-changes in DVB-T2 recordings and the following keyframe mark reported by the editor. I am looking at compensating for this in mythTScut (work in progress) which cuts at keyframes found by ffmpeg.
comment:20 Changed 7 years ago by
The seektable generated for your latest sample looks right in cut-list editor.
Broadcast TS files typically have offset between audio & video packets (with matching PTS) to allow post processing time for de-iterlace etc.
You'll notice that mpv & VLC start typical broadcast TS recording playback with audio & no video because there is no video packet with matching PTS at start.
AFAIU MythTV uses video PTS as time zero & mkvtoolnix & ffmpeg etc use earliest (time) PTS as time zero & this will be audio PTS in our recordings. I confirmed this behaviour of mkvtoolnix with the author. This is why "losslesscut" (mkvtoolnix time based) works fine with HDPVR recordings (60p samples seem to have 10's ms AV pkt PTS delta) & was never frame accurate for real-world broadcast TS files. I do have one sample 50p recording believed to be HDPVR that has 4 second delta audio to video!
The TS cutting script, that I use, is file-offset based & is frame accurate & as fast as file copy. It just does not handle the AV pkt PTS delta.
Your file has about 0.7sec (18 frame intervals) packet PTS delta. Could this time delta be the frame offset error you see with external cutting tool? You can extract this time delta with mediainfo & use it to offset the keyframe times.
Have wondered if re-muxing TS recordings first to remove the AV delta & then generating cut-list would eliminate most problems of frame accuracy.
comment:21 Changed 7 years ago by
I'm making fitful progress with this, and the 7-frame mismatch seems unexpected but not critical. Here's a -v playback frontend log, as a video, over an ad-break. The output video editpoints were well placed; but some other breaks still create and recover from bigger slippages, and playback may skip frames that the editor reveals. Playback still isn't as smooth as that of the original recording with the same cutlist. Testing takes time, too...
All the cutting is done after a first run with no cutlist. I don't know if this will remain a necessity.
ITV HD 21605_20180101185800_8793.ts 00:34:47.6000 2087600 ms computed output position
2018-04-07 22:05:27.401265 I Player(9): FPS: 25.00 Mean: 39995 Std.Dev: 319 CPUs: 5% 4%
2018-04-07 22:05:31.401270 I Player(9): FPS: 25.00 Mean: 39995 Std.Dev: 725 CPUs: 4% 5%
2018-04-07 22:05:35.401306 I Player(9): FPS: 25.00 Mean: 39995 Std.Dev: 1250 CPUs: 5% 5%
2018-04-07 22:05:36.921022 I Player(9): 3600 progressive frames seen.
2018-04-07 22:05:39.401285 I Player(9): FPS: 25.00 Mean: 39994 Std.Dev: 1819 CPUs: 5% 4%
2018-04-07 22:05:43.401266 I Player(9): FPS: 25.00 Mean: 39995 Std.Dev: 167 CPUs: 5% 5%
2018-04-07 22:05:45.211071 I Player(9): Video is 3.09232 frames ahead of audio,
doubling video frame interval to slow down.
2018-04-07 22:05:45.303021 I Player(9): Video is 3.45047 frames ahead of audio,
doubling video frame interval to slow down.
2018-04-07 22:05:45.371063 I Player(9): Video is 3.3941 frames ahead of audio,
doubling video frame interval to slow down.
2018-04-07 22:05:45.451077 I Player(9): Video is 3.17683 frames ahead of audio,
doubling video frame interval to slow down.
2018-04-07 22:05:47.667918 I Player(9): FPS: 23.44 Mean: 42661 Std.Dev: 9369 CPUs: 5% 4%
2018-04-07 22:05:51.667948 I Player(9): FPS: 25.00 Mean: 39994 Std.Dev: 767 CPUs: 5% 4%
2018-04-07 22:05:53.187689 I Player(9): 4000 progressive frames seen.
2018-04-07 22:05:55.667919 I Player(9): FPS: 25.00 Mean: 39995 Std.Dev: 484 CPUs: 3% 3%
2018-04-07 22:05:59.667945 I Player(9): FPS: 25.00 Mean: 39995 Std.Dev: 647 CPUs: 5% 5%
2018-04-07 22:06:03.667950 I Player(9): FPS: 25.00 Mean: 39995 Std.Dev: 1384 CPUs: 8% 4%
2018-04-07 22:06:07.667937 I Player(9): FPS: 25.00 Mean: 39995 Std.Dev: 1823 CPUs: 3% 3%
2018-04-07 22:06:09.187687 I Player(9): 4400 progressive frames seen.
2018-04-07 22:06:11.667947 I Player(9): FPS: 25.00 Mean: 39995 Std.Dev: 715 CPUs: 4% 4%
comment:22 Changed 7 years ago by
Continuing from comment 19 above: I've made a little progress in using ffprobe and can now see where it thinks keyframes are. I suspect that the lack of cutting-precision in my script may have more to do with the handling of timecodes, but here's some food for thought from a very short recording from BBC ONE HD DVB-T2
[john@HP_Fed ~]$ ffprobe -show_frames "/home/john/SGs/RecsSG2/21540_20180415204200.ts_24722in.ts" 2> /dev/null | grep -B16 -A1 pict_type=I | head -n 18
This is from the raw recording
stream_index=0
key_frame=1
pkt_pts=5493778274
pkt_pts_time=61041.980822
pkt_dts=5493778274
pkt_dts_time=61041.980822
best_effort_timestamp=5493778274
best_effort_timestamp_time=61041.980822
pkt_duration=3600
pkt_duration_time=0.040000
pkt_pos=89864
pkt_size=92220
width=1920
height=1080
pix_fmt=yuv420p
sample_aspect_ratio=1:1
pict_type=I
coded_picture_number=11
[john@HP_Fed ~]$ ffprobe -show_frames "/home/john/SGs/RecsSG2/21540_20180415204200.ts_25372in.ts" 2> /dev/null | grep -B16 -A1 pict_type=I | head -n 18
This is from mythTScut R 1 NC on the raw recording
stream_index=0
key_frame=1
pkt_pts=274007
pkt_pts_time=3.044522
pkt_dts=274007
pkt_dts_time=3.044522
best_effort_timestamp=274007
best_effort_timestamp_time=3.044522
pkt_duration=3600
pkt_duration_time=0.040000
pkt_pos=22184
pkt_size=92220
width=1920
height=1080
pix_fmt=yuv420p
sample_aspect_ratio=1:1
pict_type=I
coded_picture_number=4
[john@HP_Fed ~]$
[john@HP_Fed ~]$ ffprobe -show_frames "/home/john/SGs/RecsSG2/21540_20180415204200.ts" 2> /dev/null | grep -B16 -A1 pict_type=I | head -n 18
This is from a segment cut out by mythTScut R 1 from the file above
stream_index=0
key_frame=1
pkt_pts=181007
pkt_pts_time=2.011189
pkt_dts=181007
pkt_dts_time=2.011189
best_effort_timestamp=181007
best_effort_timestamp_time=2.011189
pkt_duration=3600
pkt_duration_time=0.040000
pkt_pos=3760
pkt_size=126831
width=1920
height=1080
pix_fmt=yuv420p
sample_aspect_ratio=1:1
pict_type=I
coded_picture_number=4
[john@HP_Fed ~]$ ffprobe -show_frames "/home/john/SGs/RecsSG2/21540_20180415204200.ts" 2> /dev/null | grep -A1 pict_type=I | head -n 20
From the same cutout segment
Keyframes from the editor are 1, 25, 49, 73, 83, 110, 134
pict_type=I
coded_picture_number=4
--
pict_type=I
coded_picture_number=28
--
pict_type=I
coded_picture_number=52
--
pict_type=I
coded_picture_number=76
--
pict_type=I
coded_picture_number=86
--
pict_type=I
coded_picture_number=113
--
pict_type=I
coded_picture_number=137
[john@HP_Fed ~]$
[john@HP_Fed ~]$ ffprobe -show_frames "/home/john/SGs/RecsSG2/21540_20180415204200.ts_24722in.ts" 2> /dev/null | grep -A1 pict_type=I | head -n 20
The raw recording again
Keyframes from the editor are 1, 25, 49, 64, 91, 115, 142
pict_type=I
coded_picture_number=11
--
pict_type=I
coded_picture_number=35
--
pict_type=I
coded_picture_number=59
--
pict_type=I
coded_picture_number=74
--
pict_type=I
coded_picture_number=101
--
pict_type=I
coded_picture_number=125
--
pict_type=I
coded_picture_number=152
comment:23 Changed 7 years ago by
The byte offsets of keyframes (pkt_pos) as read by ffprobe in the cut segment agree with those in the rebuilt seektable as reported by getmarkup. Reassuring. Only the frame numbers differ.
comment:24 Changed 7 years ago by
| Owner: | changed from Peter Bennett to Peter Bennett |
|---|
comment:25 Changed 4 years ago by
| Resolution: | → Unverified |
|---|---|
| Status: | assigned → closed |
Closing all old tickets in trac.
If your issue still persists, please open an issue in Github https://github.com/MythTV/mythtv/issues
and reference the existing trac ticket.
Short clip from 'The Simpsons', Channel4HD
The link is being rejected as potential spam. I'll try adding it to the email thread quoted above.