Project

General

Profile

Forums » General »

Performance of seeking in recordings

Added by Richard van der Hoff about 8 years ago

Folks, I'm getting disappointing results when trying to seek forwards/backwards in recordings, and I could use a little help in understanding what is reasonable to expect.

My setup is a headless Ubuntu server running Tvheadend 4.0.9-6, with a Raspberry Pi 2 running an OSMC build of Kodi 17 as the front end.

Playback of recordings essentially works fine. Skipping ahead or backwards in increments of 30s is also fine. What doesn't work so well is trying to fast-forward or rewind at say 4x or 8x speed; basically the picture just freezes up rather than showing any video as it goes. Worse, if I rewind for a while, I often can't resume playback at all - the picture just freezes until I stop the playback altogether.

I'm aware that I'm demanding quite a lot of both the front and back-ends here, but I wonder if there is any obvious configuration that I might have missed which could help improve this.

Also: apologies if this is an idiotic question which comes up all the time. I looked through the forums and documentation, but couldn't really find anything helpful.


Replies (7)

RE: Performance of seeking in recordings - Added by Robert Cameron about 8 years ago

If I remember correctly, part of the problem with seeking a MPEG-TS live stream (whether live or recorded) is that there are no B frames to help with the display. That is why seeking a set time amount works fine, because it is moving to a specific frame; however, trying to display frames while seeking is rather intensive because there are no B/key frames to help with the decode.

RE: Performance of seeking in recordings - Added by Richard van der Hoff about 8 years ago

Mmmhmm. Good point. I might try transcoding the recordings to use fewer non-keyframes.

RE: Performance of seeking in recordings - Added by Robert Cameron about 8 years ago

Although, live transcoding doesn't insert B frames, either ...

RE: Performance of seeking in recordings - Added by Richard van der Hoff about 8 years ago

Empirically, transcoding the recording seems to help, though it's hard to get an objective measurement.

I'm somewhat confused by the 'Stream Profiles' settings in TvHeadend. Am I right in understanding that this is used to define the format used to save recordings to disk? At the moment I am using the 'pass' profile, but maybe I should be using 'htsp'? What does htsp actually do in this context?

RE: Performance of seeking in recordings - Added by Robert Cameron about 8 years ago

No, stream profiles are only for streaming live content. You set a recording profile for what happens when the stream gets recorded. They are separate and only apply to their own realms (live or recorded).

Also, stream profiles do not apply to playback of recorded content, but those are always passed on exactly as they were recorded.

RE: Performance of seeking in recordings - Added by Richard van der Hoff about 8 years ago

Thank you for answering my stupid questions, and I'm aware we're drifting away from my original subject, but sorry, I'm more confused than ever.

Also, stream profiles do not apply to playback of recorded content, but those are always passed on exactly as they were recorded.

So what does the "Stream Profile" setting on the "DVR profiles" page (pictured) do?

Screenshot_2016-11-27_20-47-58.png (130 KB) Screenshot_2016-11-27_20-47-58.png

RE: Performance of seeking in recordings - Added by Robert Cameron about 8 years ago

The stream profile for the recording is how it is recorded. So, if you want to record only the original MPEG2 stream, you would set this to pass. If you prefer a 720 h264 transcoded stream for viewing live TV, then that is what would be sent for live. However, if you choose to watch a recorded program (that was recorded with the pass profile), it would send the MPEG2 stream as it was recorded, and not transcode it as indicated by your preferred streaming profile.

(It would be easier to understand if it was named something different, but that is how it is at present.)

    (1-7/7)