[mythtv] Seektable problems

[Peter Bennett]

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