Mailing List Archive

Seektable problems
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
Re: Seektable problems [ In reply to ]
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







_______________________________________________
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
Re: Seektable problems [ In reply to ]
I do have a related query with editing DVB-T radio and my old
'audiograph' ticket #12901. With these recordings 'timecode' is 0 on
entry at

/mythtv/libs/libmyth/audio/audiooutputgraph.cpp line 50,

which seems perverse but might perhaps be signalling something else. I
spent quite a lot of effort some time ago trying to get a genuinely
useful display, but eventually (sour grapes?) concluded that ears were
better.

John
_______________________________________________
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
Re: Seektable problems [ In reply to ]
Peter Bennett wrote:
> 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.
I created two H265 sample recordings for this bug report. You find the
download links in the attachments.

#13211: MythTV needs a backport from FFmpeg 3.3/3.4 to make German
DVB-T2 HD with 5.1 audio work
https://code.mythtv.org/trac/ticket/13211

I can create more H265 recordings.

Greetings,
Björn
_______________________________________________
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