Opened 15 years ago

Closed 14 years ago

Last modified 14 years ago

#6982 closed defect (fixed)

FF/Rew speed is way off for HD-PVR recordings

Reported by: gigem Owned by: gigem
Priority: minor Milestone: unknown
Component: MythTV - General Version: unknown
Severity: medium Keywords:
Cc: Ticket locked: no

Description

The actual FF/Rew speed for HD-PVR recordings is much higher than the intended speed. This is actually a long standing problem that affects most recordings, but is most apparent with HD-PVR recordings due to their exceptionally large keyframe distance.

When fast forwarding and rewinding, NVP tries to synthesize the desired FF/Rew speed by using the actual keyframe distance to calculate how many frames to skip forward or backward in a nominal display interval of 200ms. The problem is that when all of the encoders were switched to generate by-frame position maps, the decoders were also changed to use and report an artificial keyframe distance of 1.

For recordings with typical keyframes distances in the range of 12-15, the affect on NVP when calculating the skip count is minor, so I, and apparently nobody else, bothered to complain. For HD-PVR recordings, however, the actual keyframe distance is fairly high and causes the calculated skip interval to be way too low. In fact, for modest FF/Rew speeds, the calculated skip interval can be less than the actual keyframe distance! The end result is a much higher actual FF/Rew speed than intended because the decoder seeks further than NVP expects.

Unfortunately, the simple fix restoring the actual keyframe distance as detected by the decoders doesn't work. It seems the use of the artificial keyframe distance of 1 is too closely intertwined with the by-frame position maps and other things. Suggestions are welcome on how to either provide the actual keyframe distance to the FF/Rew code in NVP or untangle the by-frame position maps from the keyframe distance.

Change History (7)

comment:1 Changed 15 years ago by Johnny Stenback <mythtv@…>

FWIW, what I see with my setup when watching HD-PVR recordings is that if I hit the fastforward button once, the osd says it's fast forwarding at 3x speed, audio turns off, but the speed doesn't actually change noticeably, if at all (and watching the seconds tick by in the osd, it seems like the speed is 1x, not 3x). If I hit fast forward again, the reported speed in the osd changes to 5x, but the actual speed is more like 20x or somesuch. I'm assuming both the lack of speedup at 3x is the same problem as described above, if not, let me know and I can open a new ticket.

comment:2 in reply to:  1 Changed 15 years ago by gigem

The 3x behavior you see is a different problem altogether. The reason is 3x is a magic value. For anything <= 3x, Myth tries to play every frame, just faster. For speeds > 3x, Myth only plays selected frames to achieve the desire speed. I think there's been a bug around for awhile where speeds between 2x and 3x don't work correctly.

The behavior you see where 5x really looks like 20x or more is what this bug report is all about. I'm working on it, albeit slowly.

comment:3 Changed 15 years ago by markk

(In [21890]) Fix an a/v sync error when fast forwarding at 5x and higher speeds. In certain situations (and nearly always when using VDPAU), a pre-buffering state would trigger a re-start of the video sync which in turn meant that the video loop was always 'late' for the next sync. As a result video frames were displayed as fast as the hardware could handle. Refs #6982.

comment:4 Changed 14 years ago by gigem

Resolution: fixed
Status: newclosed

(In [22539]) When calculating the frame skip amount for fast-forward/rewind, use an arbitrary value of 30 as the keyframe distance instead of the bogus value of 1 that is currently used. I had hoped to have the decoder pass the actual keyframe distance to NVP, but that won't work for recordings with variable keyframe distances. Using 30 as the keyframe distance is a compromise that helps some on HD-PVR recordings without adversely affecting other recordings too much. Fixes #6982.

comment:5 Changed 14 years ago by gigem

(In [22540]) Backport of [22539] to release-0-22-fixes.

When calculating the frame skip amount for fast-forward/rewind, use an arbitrary value of 30 as the keyframe distance instead of the bogus value of 1 that is currently used. I had hoped to have the decoder pass the actual keyframe distance to NVP, but that won't work for recordings with variable keyframe distances. Using 30 as the keyframe distance is a compromise that helps some on HD-PVR recordings without adversely affecting other recordings too much. Refs #6982.

comment:6 Changed 14 years ago by gigem

(In [22547]) Fixed reversed fast-forward/rewind check introduced in [22539] and [22540]. Ugh, I know better than to make a "trivial change" at the last minute and not retest before committing! Fixes #7374 Refs #6982.

comment:7 Changed 14 years ago by gigem

(In [22548]) Fixed reversed fast-forward/rewind check introduced in [22539] and [22540]. Ugh, I know better than to make a "trivial change" at the last minute and not retest before committing! Fixes #7374 Refs #6982.

Note: See TracTickets for help on using tickets.