[mythtv] Seektable problems

[John Pilkington]

On 17/01/18 17:06, Peter Bennett wrote:
> There are some problems around the seek table that do not have immediate 
> solutions.
> 
> 1. H265 recordings get an incorrect seek table and this causes problems. 
> See ticket https://code.mythtv.org/trac/ticket/12993.
> 2. Depending on the content, regenerating the seek table for an H264 
> recording causes some problems. See ticket 
> https://code.mythtv.org/trac/ticket/12010
> 3. Generating a seek table for an mkv file is a waste of resources, it 
> reads through the entire file then creates no seek table. See 
> https://lists.gt.net/mythtv/users/536443#536443. It works better to just 
> delete the seek table with mythutil.
> 
> The creating of the seek table is done in two places: During recording 
> by the recorder, and in mythcommflag when using the --rebuild option. In 
> both cases we are using parsers in MythTV code, MPEG parser and H264 
> parser. During recording, anything that is not H264 is passed to the 
> MPEG parser, which creates wrong entries for H265 content. During 
> mythcommflag It specifically checks for MPEG and H264 and anything else 
> is not parsed, which means no seektable entries are generated.
> 
> The consequences of having no seektable are that you cannot edit, and 
> maybe commercial flagging won't work. Actual seeking seems to work well 
> without a seek table, although the h265 user said there was 1 second of 
> pixellation after seeking.
> 
> Deleting the seektable for an MPEG2 recording that is interlaced results 
> in MythTV thinking it is twice the length. In the progress bar it shows 
> the program as 2 hours instead of 1 hour, but skipping and playing is 
> fine. When the progress bar gets to 50% the playback ends.
> 
> I did some work trying to get the seektable to generate for h264 mkv 
> files. With some changes, I got it to work. However it did not speed up 
> searches. Editing worked but cut points were not skipped accurately 
> during playback. So I decided to abandon that.
> 
> So the question is - what should be done for those areas that are not 
> working, such as H265? I suggest that we change the recorder to skip the 
> seek table on H265 for the short term fix. For long term, should we 
> start writing parsers for H265 and other types of content, or eliminate 
> the seek table and try to make the editor work without it? For H265 
> pixellation after seeking perhaps we could build something into the 
> player to search for an IDR frame after skipping, using the decoded 
> stream rather than by writing our own parser.
> 
> I do not have access to any H265 broadcasts, so maybe somebody in 
> Germany can look at the recorder problem (recording H265 without 
> creating a seek table). I can look at the playback side of it if I get a 
> sample recorded file.
> 
> Peter

I just repeated what I did 3 years ago in #12010 on a short recording 
from BBC TWO HD (DVB-T2 h264), with similar results.  Latest 'buntu 
build of Master, v30pre366.

Strangely the column layouts are different in the --getmarkup output for 
the raw and rebuilt seektables but the byte offsets found are identical. 
  The frame numbers and timestamps again drift apart, this time by 3 
frames or 120 ms in about 5 minutes; at the discontinuities the rebuilt 
frame numbers advance, as usual, by 24 while with the raw ones it's 
sometimes 23.

For my purposes I don't see a problem here, and editing SD mpeg2 seems 
fine too.  I haven't used mkv or h265.

John P