Short seeks intolerably slow with HDPVR and vdpau

[mythtv@…]

I have my frontend (running 0.27 from atrpms) configured with 30 second forward seeks, and 5 second sticky backwards seeks. Seeking forwards or backwards 5 seconds takes way too long, sometimes a few seconds. I believe this is caused by the changes in 4d0bbbe1e54aaa91abbd233b7e5a1a48103462f2 (Remove the "Seek to exact frame" setting.) combined with HDPVR putting keyframes 4 seconds apart and vdpau taking a long time to decode frames.

For a 5 second seek, the chance of finding a keyframe in an HDPVR stream within 10% of the seek (+/- .5 seconds) is small, so it almost always ends up starting from the previous keyframe and then decoding up to 3 seconds of frames, which seems to take a few seconds with the vdpau decoder. An easy fix (suggested by jpoet in #11882) is to change the kInaccuracyDefault from 0.1 to 0.5, which for a 5 second seek will look in the range 2.5-7.5 seconds and will always find a keyframe on an HDPVR stream. I've attached a patch to do that.

Other ideas: Change the seek accuracy to be a constant 5 seconds

Mark the vdpau decoder as being slow, and use that flag to determine how aggressive to be about forcing seeks to exact keyframes.

[mythtv@…]

Patch to change default seek accuracy to 50%

[Jim Stichnoth]

Proof of concept.

[Jim Stichnoth]

For background, MythTV seeking works by first quickly seeking to the nearest preceding keyframe, then decoding forward, frame by frame, until the desired frame is reached. For an HD-PVR, that can be up to 127 frames, and since some Nvidia hardware can decode HD-PVR recordings only slightly faster than real time (also true for CPU decoding), this can sometimes take several seconds. If you try to take a shortcut and seek directly to the target frame, you end up with bad pixelation until the next keyframe is displayed.

The current code tries to soften this delay by assuming that further-away seeks can tolerate higher inaccuracy. When the tolerance allows, it snaps to the nearest keyframe and avoids slow frame-by-frame decoding. This is an improvement much of the time, but the unpredictable long delays for some short seeks severely detracts from the user experience.

I think this approach can be vastly improved by limiting the frame-by-frame decoding to a certain length of time - a fraction of a second - in most cases. I attached a proof-of-concept patch that limits the search to 100ms for all seeks. (A real solution would probably use a higher limit, and would not enforce a time limit in certain cases like single-frame seeking, seeking to a bookmark, and mythpreviewgen seeking.) Feedback appreciated.

[mythtv@…]

How fast do you expect the fastest decoder to be able to decode a frame? Is it going to make any significant progress in 100 ms?

For anything that is near-realtime, like vdpau, it makes more sense to just start the display at the keyframe instead of spending 100 ms decoding, and then starting display close to the keyframe + 100 ms, especially if the 100 ms needs to be increased to something more like 500 ms. The only time you would ever want an exact-seek on a realtime decoder is for the single-frame, bookmark, and mythpreviewgen seeking.

What about letting the decoder override the default seek accuracy, and setting it to -1.0 in the vdpau decoder?

[mythtv@…]

I did a quick test measuring the frame-by-frame seek time on a decent ffmpeg decoded frontend (i7-3520M) with an hdpvr h264 stream, and came up with 648 ms to seek 95 frame, about 7 ms per frame. At that speed it still doesn't make sense to me to spend 100ms decoding frames just to skip over 14 out of 95 frames after the keyframe.

The advantage of your idea is that it is adaptive - on slow decoders you get something like keyframe seeking, on fast decoders you get exact seeking, but I think 100 ms is going to be too short to be useful, and a higher time would negatively impact seek times on slow decoders. I've attached a patch that tries to predict the longer decoding time after the first 5 frames and then short-circuit the rest of the decoding. Its still set to limit to an expected 100 ms, but it could be increased to 500 ms without causing effectively all of my seeks to take 500 ms.

[JYA]

any update on this?

[Jim Stichnoth]

seek_v2.patch makes a couple of changes to the predictive version. It disables the optimization when exact seeks are required. Description (from the comments in the patch):

    // First, we impose an absolute maximum time we are willing to
    // spend (maxSeekTimeMs) on the forward frame-by-frame skip.
    // After that much time has elapsed, we give up and stop the
    // frame-by-frame seeking.  Second, after skipping a few frames,
    // we predict whether the situation is hopeless, i.e. the total
    // skipping would take longer than giveUpPredictionMs, and if so,
    // stop skipping right away.

Again, feedback appreciated.

[Jim Stichnoth]

Within the cutlist editor, use full accuracy when seeking less than 1 second.

[JYA]

minor comment: Should replace:

QTime begin; 
begin.start(); 

with:

MythTimer begin(MythTimer::kStartRunning);

for clarity/style sake

[Jim Stichnoth <jstichnoth@…>]

In 33acfaf30747592b9fca0913b2c2f8832418d618/mythtv:

Make seeks faster for slow decoders / large keyframe distances.

Exact seeking for HD-PVR recordings can be notoriously slow because
the keyframe distance is 128 frames and decoding (even GPU hardware
decoding) is often little faster than real-time.

In most cases, it's a much better user experience to make a less
accurate but much faster seek to the preceding keyframe.

There are two changes:

1. Impose a maximum wall-clock time on the forward frame-by-frame

seeking. After this maximum time elapses, abort any further frame
seeking.

2. In addition, try to predict whether fully accurate seeking will

complete within a reasonable time, and if after a few frames it seems
hopeless, just don't bother seeking any further.

This approach allows fast decoders and video formats amenable to fast
decoding to continue to have exact seeking.

Fixes #12004.

[Jim Stichnoth <jstichnoth@…>]

In 6788ea9ab34b86a1b7f18a540f91d5c5514f4665/mythtv:

Make seeks faster for slow decoders / large keyframe distances.

Exact seeking for HD-PVR recordings can be notoriously slow because
the keyframe distance is 128 frames and decoding (even GPU hardware
decoding) is often little faster than real-time.

In most cases, it's a much better user experience to make a less
accurate but much faster seek to the preceding keyframe.

There are two changes:

1. Impose a maximum wall-clock time on the forward frame-by-frame

seeking. After this maximum time elapses, abort any further frame
seeking.

2. In addition, try to predict whether fully accurate seeking will

complete within a reasonable time, and if after a few frames it seems
hopeless, just don't bother seeking any further.

This approach allows fast decoders and video formats amenable to fast
decoding to continue to have exact seeking.

Fixes #12004.
(cherry picked from commit 33acfaf30747592b9fca0913b2c2f8832418d618)