[vdr] vdr-xine trickspeed bug report

Joerg Riechardt J.Riechardt at gmx.de
Wed Apr 13 12:55:28 CEST 2011


Am 10.04.2011 20:18, schrieb Joerg Riechardt:
> 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
>>> PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP
>>> ...
>>> 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.
>
> Hi,
>
> 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.
>
> Joerg

Hi,
I do have both mentioned settings in my .xine/config.
I did a test with xineliboutput and got no distortions (except sometimes 
at the very beginning) when starting slow forward from an I-Frame.
So I guess this *is* a vdr-xine bug. Although probably not a very 
important one.
And vdr-xine is still my favourite, so thanks for all your work on it!
Joerg



More information about the vdr mailing list