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

Am 13.04.2011 12:55, schrieb Joerg Riechardt:

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

btw. this happens with the new decoder as well. Joerg