Opened 14 years ago

Closed 10 years ago

#137 closed defect (wontfix)

curious behaviour on rewinding

Reported by: Simon Kenyon <simon@…> Owned by: danielk
Priority: minor Milestone: unknown
Component: mythtv Version: head
Severity: low Keywords:
Cc: Ticket locked: no

Description

when i rewind in live-tv and then play, the first frame of the ringbuffer is displayed for a brief moment before the current frame (to which you had rewound).

i realised this yesterday when i changed channel in live-tv and the beginning of the recording had a really nasty diagonal orange wipe (ok, so it *was* MTV). after watching a bit, there was a piece i wished to replay, so i rewound and when i got to where i wanted to watch again i hit play; to be greeted by that nasty orange wipe for about 1/10th of a second.

it might be related to the issue where if you cut the first part of a recording it always plays the first frame. sort of messes the experience :-)

Change History (10)

comment:1 Changed 14 years ago by anonymous

I see this too, I've seen it for a while.

comment:2 Changed 14 years ago by danielk

Milestone: 0.20
Owner: changed from Isaac Richards to danielk
Status: newassigned
Version: head

I believe I know the cause of this. It's due to the fallback mechanism to a previous frame. It is, but shouldn't be, looking at frames from before a skip.

Unless you are using XvMC this probably happens because the pause frame contains stale data. With XvMC it is a little more complicated.

The effect is trivial but fixing it is not so trivial due to XvMC, so I'm pushing it to the next release on my fix queue.

comment:3 Changed 13 years ago by danielk

Resolution: fixed
Status: assignedclosed

I'm pretty sure this is fixed in svn.

comment:4 Changed 13 years ago by danielk

(In [10143]) Refs #906. Refs #137. Backports XvMC fixes from SVN head to 0.19-fixes.

This is slightly more hackish than the fix in head, because I didn't backport some of the NVP fixes that simplify the XvMC fixes there.

But I've made hundreds of channel changes and many skips and playback speed changes and it only gave me stuttering once vs. 10% of the time without the fixes.

comment:5 Changed 13 years ago by danielk

Resolution: fixed
Status: closedreopened

From Simon on mailing list:

sounds reasonable - if i cannot describe it - how could you fix it. i use a recording, because then it is repeatable

having said that - i'm finding it hard to see a pattern maybe this is a red herring, but "seek to exact frame" seems to have an affect

if i start fast forwarding or rewinding, i not the picture on the screen at the start, then i move to a section of the recording with a completely different scene. then i stop going forward to backwards by hitting "enter" to play. for a brief period, the frame that i started with appears.

when i first reported it, the frame displayed used to be the first frame of the recording. i think that is no longer the case.

describing the problem is a little more complicated as when i move from fast forward to play, myth seems to jump back a variable amount, from none to 1 or 4 seconds, so i have to keep two scenes in my head, the one i started with and the one i finish fast-fwd/rew on.

when editing, everything is frame perfect. pity that code cannot be used. is it fast enough?

comment:6 Changed 13 years ago by danielk

Milestone: 0.200.21

comment:7 Changed 13 years ago by simon kenyon

i know the usual applies (don't complain if you don't contribute) but apart from the UI rewrite this is the oldest ticket in trac

will it be possible to fix this at some point? at one point you thought you had.

comment:8 Changed 12 years ago by danielk

Milestone: 0.21unknown

comment:9 Changed 11 years ago by Dibblah

Status: newassigned

comment:10 Changed 10 years ago by danielk

Resolution: wontfix
Status: assignedclosed

XvMC as a standard appears to have been abandoned for new APIs so little reason to bother with this corner case which doesn't cause major problems.

Note: See TracTickets for help on using tickets.