HEVC/H265 Parser missed for Recordings

[laasa@…]

Because there exist no HEVC/H265 parser inside libmythtv (called in DTVRecorder::ProcessVideoTSPacket) there are no information about the video quality in the recording view.

For German DVB-T2 HD this could be fixed by an easy fix (set height to 1080, width to 1920 and frameRate to 50). When DVB-T2 HD the only HEVC source it might be OK.

But at the end a new module is needed similar to mythtv/libs/libmythtv/mpeg/H264Parser.cpp.

[laasa@…]

Another result of the missing parser is that the forward / rewind is not working or not working correct when playing the recordings. It looks like that MARK_TOTAL_FRAMES is not set correct in recordedmarkup table.

[bjoernv@…]

I also found, that forward / rewind does not work precisely for HEVC/H265 recordings. Also, if the timeline already shows, that the recording is finished, it may play some minutes longer.

[bjoernv@…]

Instead of writing a new HEVCParser (a HEVC/H.265 variant of the existing mythtv/libs/libmythtv/mpeg/H264Parser.cpp parser) from scratch, it may be a good idea to base on the existing FFmpeg parsers.

Newer versions of FFmpeg including FFmpeg 3.2 included in MythTV 29, have a parser called h2645_parse (mythtv-29/mythtv/external/FFmpeg/libavcodec/h2645_parse.c). The HEVC code (mythtv-29/mythtv/external/FFmpeg/libavcodec/hevc_parse.c) is small, because most functions are inherited from h2645_parse.

I can not estimate, how much work this will be.

Since none of the VDR systems for Linux currently have full support for the German DVB-T2 HD (HEVC codec) TV standard, some people work on hacks, which work more or less. Here people from Linux DVR have made patches for HEVC:

[RFC] H.265 Frame-Parser ​https://www.vdr-portal.de/forum/index.php?thread/128740-rfc-h-265-frame-parser/ (in German)

[bjoernv@…]

Yesterday I recorded 90 minutes movie (German DVB T2 HD HEVC). I wanted to stop watching at 60 minutes and tried to set a bookmark. Unfortunately MythTV miscalculated the movie length (around 60 minutes), so that it was not possible to set the bookmark. Today MythTV frontend shows a video length of 1:26:46 (around 86 minutes). The video length calculation is very unreliable for HEVC.

[Peter Bennett]

It looks like dtvrecorder it caters for H264 or MPEG2. Worse is that if the stream is not H264 it is treated as MPEG2. So it appears your H265 broadcast is being treated like MPEG2.

If it creates a seektable based on wrong assumptions, seeking and recording length will be affected. It may be better to have no seektable at all. You could try deleting the seektable and see if that helps.

I would think the continuity detection would also be wrong. Is your recording being flagged as failed?

The frame parser you mention only splits the packet into NAL units. We need more information from the packet, in particular the location of key frames.

I suspect the H264 parser may work for H265 better than the MPEG2 parser works, since in the code examples the H265 parser seems to be based on the H264 parser. I do not have access to any H265 broadcasts so I cannot test this. Perhaps somebody could try it out.

[bjoernv@…]

Replying to pbennett:

If it creates a seektable based on wrong assumptions, seeking and recording length will be affected. It may be better to have no seektable at all. You could try deleting the seektable and see if that helps.

Could you give me a hint, how to delete the seektable for a specific recording?

I would think the continuity detection would also be wrong. Is your recording being flagged as failed?

No.

The frame parser you mention only splits the packet into NAL units. We need more information from the packet, in particular the location of key frames.

I suspect the H264 parser may work for H265 better than the MPEG2 parser works, since in the code examples the H265 parser seems to be based on the H264 parser. I do not have access to any H265 broadcasts so I cannot test this. Perhaps somebody could try it out.

Would it be helpful for you, if I upload a recorded sample to Google Drive etc.?

[Peter Bennett]

Clear the seektable this way

mythutil --clearseektable --chanid 2763 --starttime 20170814180000

To get the chanid and starttime you can look at the information (press I in the watch recordings window). The file name will normally be something like 2763_20170814180000.ts or 2763_20170814180000.mpg. In either case the first 4 digits are the chanid and the rest is the start time.

To verify you can run this

mythutil --checkrecordings

That will tell you which recordings do not have seektables

The fix is really going to have to be in the recorder, so having an already recorded file will not really help much. Let's see if deleting the seektable helps, then maybe I can prevent it from creating a seektable for H265 recordings, as an interim step.

[bjoernv@…]

Replying to pbennett:

Clear the seektable this way

mythutil --clearseektable --chanid 2763 --starttime 20170814180000

Clearing the seektable seems to help. I recorded 6:13 minutes of a TV video. I verified the video length with a video editor (Avidemux). Mythfrontend showed me a video length of 5:41 minutes before clearing the seektable. After I cleared the seektable, also Mythfrontend shows 6:13 minutes.

Fast forward and reverse seems to work better after clearing the seektable. But fast forward and reverse does not jump to I-frames, so that the user has to wait around 1 second until the display is clear.

[Stuart Auchterlonie]

Peter,

We have a parser now, is there something we need to add to fix this too?

Regards Stuart

[Peter Bennett]

Fixed by John Poet in 7fc5e803134d8d429878ef062357ede8c73f1404