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
Tri
> so I guess it must be a xine-lib problem? or a deinterlacing problem?
Hmm, I don't see a general problem due xinelib, because a couple of guys are
watching BBC HD from Astra 28.2° here in Germany. Due to it's unfavorable
postion, Astra 28.2°, it is basically not easy to get, especially in the
so
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
I'm trying to record from an MPEG-2 stream and I'm getting an error
"ERROR: video data stream broken".
I've narrowed down the problem to remux.c where it's looking for the
Picture Start Code (0x0100) and it's never finding it so it's
timing out. I'm not exactly sure why this is happening sinc
Hi
Did you try this patch ?
http://permalink.gmane.org/gmane.linux.vdr/42765
We have the same kind of problem in France, picture start code equal zero and
not 1 as define in mpeg standard
@+
Le Sunday 10 April 2011 22:09:31 John Klimek, vous avez écrit :
> I'm trying to record from an MPEG-2
Hmmm, is that the right patch that you linked to?
It appears to fix an I-frame detection problem and not a picture start
code problem. (The patch fails on vdr 1.7.17, but it looks like it
belongs inside the if statement for the picture start code [ie. it
only executes that code after the start co
