curious behaviour on rewinding

[Simon Kenyon <simon@…>]

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 :-)

[anonymous]

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

[danielk]

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.

[danielk]

I'm pretty sure this is fixed in svn.

[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.

[danielk]

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?

[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.

[danielk]

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.