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
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
