[vdr] vdr-xine trickspeed bug report

Joerg Riechardt J.Riechardt at gmx.de
Sun Apr 10 20:18:31 CEST 2011

Am 10.04.2011 13:30, schrieb Reinhard Nissl:
> Hi,
> Am 08.04.2011 19:45, schrieb Joerg Riechardt:
>> In the replay of a h264 720p recording I am paused at a mark.
>> 1. Now I press right and start slow motion forward at 1/8 speed.
>> The log shows
>> TrickSpeed: 8
>> TrickSpeedMode: push H.264 SequenceEndCode
>> TrickSpeedMode: push H.264 SequenceEndCode
>> TrickSpeedMode: push H.264 SequenceEndCode
>> TrickSpeedMode: push H.264 SequenceEndCode
>> PPPPTrickSpeedMode: push H.264 SequenceEndCode
>> PPPPPPPPTrickSpeedMode: push H.264 SequenceEndCode
>> ...
>> In the rythm of the SequenceEndCode messages I see distortions
>> and hold-ups in the video flow. The start is immediate.
>> 2. This time starting at the mark I press play, pause, right and
>> start slow motion forward at 1/8 speed. The log shows
>> TrickSpeed: 8
>> ...
>> The start is delayed, but there are no distortions and the video
>> flow is steady.
>> So I guess there is something wrong with the SequenceEndCode
>> detection in 1. and in 2. with the delayed start.
> You describe slow backward and slow forward behavior of VDR (and 
> vdr-xine behavior in case of H.264 recordings). For the latter, VDR 
> sends all pictures and xine replays them at reduced speed for slow 
> motion. In case of slow backward, VDR sends only I-frames like it does 
> for fast forward or fast backward, but at a much slower replay speed.
> As for all trickspeed modes which only transfer I-frames, vdr-xine 
> inserts a H.264 SequenceEndCode between each frame to flush the frame 
> immediately to screen, because the current H.264 decoder first fills 
> its DPB with 16 frames before it outputs them on screen. For all other 
> trickspeed modes (i. e. slow forward) you see the delay of filling the 
> DPB.
> Regarding your distortions, disable deinterlacing in xine and verify, 
> that your distortions go away besides that every second line of the 
> image appears in background color. To fix this issue please apply a 
> patch to VDR-1.7.17 (which was issued on this mailing list) regarding 
> frame detection and rebuild your index file.
> Besides that you should also check the following settings in 
> .xine/config:
> # disable decoder flush at discontinuity
> # bool, default: 0
> engine.decoder.disable_flush_at_discontinuity:1
> # disable decoder flush from video out
> # bool, default: 0
> engine.decoder.disable_flush_from_video_out:1
> Bye.


thanks for your explanation.

Maybe I was not clear enough. I was *not* describing slow backward and 
slow forward.
*Both* logs were with slow forward, the difference was that in 1. the 
replay was started from pause at an I-Frame and in 2. the replay was 
started from pause in between two I-Frames, so from a non-I-Frame. So 
starting from an I-Frame leads to a different result than starting from 
a non-I-Frame. For me that was unexpected and interesting.
 From your explanation it seems to me, that 2. is the behaviour you 
expect for slow forward.
But 1. was also slow forward, not slow backward.

1. seems to show, that an immediate start is possible also for slow 
forward. And the short delays in the video flow reminded me a little bit 
of the delays with newer nvidia drivers. Only in 1. they are in the 
rythm of the I-Frames. So I thought maybe there is something to find out 
from this.

I have the mentioned frame detection patch applied, so this happened 
with that patch.
If I remember right, I have also both those settings in my .xine/config. 
I am not at home right now.


More information about the vdr mailing list