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
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
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
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org