Hi, I have a problem with skipping during a replay of a HD recording. Running xine --verbose=2 I see after pressing the yellow button (skip +60 sec) lots of video_out: throwing away image with pts xxxxxxx because it's too old (diff : yyyyy) messages. This is for a few seconds or forever, depending on system load, and causes 100% Cpu, and spoils recordings on my slow system. On faster systems you will hardly notice this. If I patch cDvbPlayer::SkipSeconds with - readIndex = Index - 1; // Action() will first increment it! + readIndex = Index; // Index - 1 causes problems in xine I no longer get those „throwing away image“ messages and the Cpu peak is only short and not that high.
This happens also for starting a replay and for resuming replay after fast forward, but for those I have no vdr patch.
I would very much appreciate if somebody with deeper knowledge of the interplay between vdr <-> vdr-xine <-> xine-lib would look into and comment on this.
You find more information at http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv-dvb-s2/p99... (german).
Without patch the video plugin gets loaded first, the audio plugin second. With patch the video plugin gets loaded second, the audio plugin first. Don´t know if that is important.
Joerg
On Thu, Mar 31, 2011 at 8:27 AM, Joerg Riechardt J.Riechardt@gmx.de wrote:
Hi, I have a problem with skipping during a replay of a HD recording. Running xine --verbose=2 I see after pressing the yellow button (skip +60 sec) lots of video_out: throwing away image with pts xxxxxxx because it's too old (diff : yyyyy) messages. This is for a few seconds or forever, depending on system load, and causes 100% Cpu, and spoils recordings on my slow system. On faster systems you will hardly notice this. If I patch cDvbPlayer::SkipSeconds with
- readIndex = Index - 1; // Action() will first increment it!
- readIndex = Index; // Index - 1 causes problems in xine
I no longer get those „throwing away image“ messages and the Cpu peak is only short and not that high.
This happens also for starting a replay and for resuming replay after fast forward, but for those I have no vdr patch.
I would very much appreciate if somebody with deeper knowledge of the interplay between vdr <-> vdr-xine <-> xine-lib would look into and comment on this.
Are you saying that when you press skip+/-, you get a delay before the skip occurs? If so, I experience this problem too. Most of the time when I press skip+/-, there's a 4-6 second pause before the skip actually occurs. Very aggravating to say the least. The good news is that Rnissl has this problem also so there's no need to try to reproduce it -- he can already observe it locally.
Am 31.03.2011 17:48, schrieb VDR User:
On Thu, Mar 31, 2011 at 8:27 AM, Joerg RiechardtJ.Riechardt@gmx.de wrote:
Hi, I have a problem with skipping during a replay of a HD recording. Running xine --verbose=2 I see after pressing the yellow button (skip +60 sec) lots of video_out: throwing away image with pts xxxxxxx because it's too old (diff : yyyyy) messages. This is for a few seconds or forever, depending on system load, and causes 100% Cpu, and spoils recordings on my slow system. On faster systems you will hardly notice this. If I patch cDvbPlayer::SkipSeconds with
readIndex = Index - 1; // Action() will first increment it!
readIndex = Index; // Index - 1 causes problems in xineI no longer get those „throwing away image“ messages and the Cpu peak is only short and not that high.
This happens also for starting a replay and for resuming replay after fast forward, but for those I have no vdr patch.
I would very much appreciate if somebody with deeper knowledge of the interplay between vdr<-> vdr-xine<-> xine-lib would look into and comment on this.
Are you saying that when you press skip+/-, you get a delay before the skip occurs?
Well, before stable replay starts. You could run xine verbose and post your log in order to know if we are talking about the same thing, I am not sure from your description.
If so, I experience this problem too. Most of the time when I press skip+/-, there's a 4-6 second pause before the skip actually occurs. Very aggravating to say the least. The good news is that Rnissl has this problem also
How do you know? Are you in contact with him?
so there's no need to try to reproduce it -- he can already observe it locally.
On Thu, Mar 31, 2011 at 12:01 PM, Joerg Riechardt J.Riechardt@gmx.de wrote:
Are you saying that when you press skip+/-, you get a delay before the skip occurs?
Well, before stable replay starts. You could run xine verbose and post your log in order to know if we are talking about the same thing, I am not sure from your description.
Maybe I misunderstoof you. I don't have a problem playing recordings, only when using skip+/-.
If so, I experience this problem too. Most of the time when I press skip+/-, there's a 4-6 second pause before the skip actually occurs. Very aggravating to say the least. The good news is that Rnissl has this problem also
How do you know? Are you in contact with him?
Yes. However, I'm referring to the problem I described. I guess you may have a separate problem.
Am 31.03.2011 17:27, schrieb Joerg Riechardt:
Hi, I have a problem with skipping during a replay of a HD recording. Running xine --verbose=2 I see after pressing the yellow button (skip +60 sec) lots of video_out: throwing away image with pts xxxxxxx because it's too old (diff : yyyyy) messages. This is for a few seconds or forever, depending on system load, and causes 100% Cpu, and spoils recordings on my slow system. On faster systems you will hardly notice this. If I patch cDvbPlayer::SkipSeconds with
- readIndex = Index - 1; // Action() will first increment it!
- readIndex = Index; // Index - 1 causes problems in xine
I no longer get those „throwing away image“ messages and the Cpu peak is only short and not that high.
This happens also for starting a replay and for resuming replay after fast forward, but for those I have no vdr patch.
Well, for fast forward I do have a patch now, which is similar to the above: - readIndex = ptsIndex.FindIndex(DeviceGetSTC()) - 1; // Action() will first increment it! + readIndex = ptsIndex.FindIndex(DeviceGetSTC()); // -1 causes problems in xine
I applied both your patches and skipping does seem to be improved quite a bit. Something still seems a little off however.
Problem solved with this patch: --- dvbplayer.c.orig 2010-03-07 15:24:26.000000000 +0100 +++ dvbplayer.c 2011-04-02 01:57:21.016535946 +0200 @@ -320,7 +320,7 @@ if (nonBlockingFileReader) nonBlockingFileReader->Clear(); if (!firstPacket) // don't set the readIndex twice if Empty() is called more than once - readIndex = ptsIndex.FindIndex(DeviceGetSTC()) - 1; // Action() will first increment it! + readIndex = ptsIndex.FindIndex(DeviceGetSTC()); // prevents dropped frames in xine vdpau h264 delete readFrame; // might not have been stored in the buffer in Action() readFrame = NULL; playFrame = NULL; @@ -388,6 +388,8 @@ int pc = 0;
readIndex = Resume(); + int resume = readIndex; + bool firsttime = true; if (readIndex >= 0) isyslog("resuming replay at index %d (%s)", readIndex, *IndexToHMSF(readIndex, true, framesPerSecond));
@@ -452,6 +454,12 @@ else if (index) { uint16_t FileNumber; off_t FileOffset; + if (firsttime) { + if (readIndex == (resume + 32)) { + Goto((readIndex - 32));// prevents dropped frames in xine vdpau h264 + firsttime = false; + } + } if (index->Get(readIndex + 1, &FileNumber, &FileOffset, &readIndependent, &Length) && NextFile(FileNumber, FileOffset)) readIndex++; else @@ -760,7 +768,7 @@ if (Index > 0) Index = index->GetNextIFrame(Index, false, NULL, NULL, NULL, true); if (Index >= 0) - readIndex = Index - 1; // Action() will first increment it! + readIndex = Index; // prevents dropped frames in xine vdpau h264 } Play(); }
On 02.04.2011 02:38, Joerg Riechardt wrote:
Problem solved with this patch: --- dvbplayer.c.orig 2010-03-07 15:24:26.000000000 +0100 +++ dvbplayer.c 2011-04-02 01:57:21.016535946 +0200 @@ -320,7 +320,7 @@ if (nonBlockingFileReader) nonBlockingFileReader->Clear(); if (!firstPacket) // don't set the readIndex twice if Empty() is called more than once
- readIndex = ptsIndex.FindIndex(DeviceGetSTC()) - 1; // Action() will first increment it!
- readIndex = ptsIndex.FindIndex(DeviceGetSTC()); // prevents dropped frames in xine vdpau h264
delete readFrame; // might not have been stored in the buffer in Action() readFrame = NULL; playFrame = NULL; @@ -388,6 +388,8 @@ int pc = 0;
readIndex = Resume();
- int resume = readIndex;
- bool firsttime = true;
if (readIndex >= 0) isyslog("resuming replay at index %d (%s)", readIndex, *IndexToHMSF(readIndex, true, framesPerSecond));
@@ -452,6 +454,12 @@ else if (index) { uint16_t FileNumber; off_t FileOffset;
- if (firsttime) {
- if (readIndex == (resume + 32)) {
- Goto((readIndex - 32));// prevents dropped frames in xine vdpau h264
- firsttime = false;
- }
- }
if (index->Get(readIndex + 1, &FileNumber, &FileOffset, &readIndependent, &Length) && NextFile(FileNumber, FileOffset)) readIndex++; else @@ -760,7 +768,7 @@ if (Index > 0) Index = index->GetNextIFrame(Index, false, NULL, NULL, NULL, true); if (Index >= 0)
- readIndex = Index - 1; // Action() will first increment it!
- readIndex = Index; // prevents dropped frames in xine vdpau h264
} Play(); }
I can't help the feeling that this is a problem that should be addressed in xine, rather than working around it in VDR.
Klaus
Am 02.04.2011 23:18, schrieb Klaus Schmidinger:
On 02.04.2011 02:38, Joerg Riechardt wrote:
Problem solved with this patch: --- dvbplayer.c.orig 2010-03-07 15:24:26.000000000 +0100 +++ dvbplayer.c 2011-04-02 01:57:21.016535946 +0200 @@ -320,7 +320,7 @@ if (nonBlockingFileReader) nonBlockingFileReader->Clear(); if (!firstPacket) // don't set the readIndex twice if Empty() is called more than once
- readIndex = ptsIndex.FindIndex(DeviceGetSTC()) - 1; // Action() will
first increment it!
- readIndex = ptsIndex.FindIndex(DeviceGetSTC()); // prevents dropped
frames in xine vdpau h264 delete readFrame; // might not have been stored in the buffer in Action() readFrame = NULL; playFrame = NULL; @@ -388,6 +388,8 @@ int pc = 0;
readIndex = Resume();
- int resume = readIndex;
- bool firsttime = true;
if (readIndex >= 0) isyslog("resuming replay at index %d (%s)", readIndex, *IndexToHMSF(readIndex, true, framesPerSecond));
@@ -452,6 +454,12 @@ else if (index) { uint16_t FileNumber; off_t FileOffset;
- if (firsttime) {
- if (readIndex == (resume + 32)) {
- Goto((readIndex - 32));// prevents dropped frames in xine vdpau h264
- firsttime = false;
- }
- }
if (index->Get(readIndex + 1, &FileNumber, &FileOffset, &readIndependent, &Length) && NextFile(FileNumber, FileOffset)) readIndex++; else @@ -760,7 +768,7 @@ if (Index > 0) Index = index->GetNextIFrame(Index, false, NULL, NULL, NULL, true); if (Index >= 0)
- readIndex = Index - 1; // Action() will first increment it!
- readIndex = Index; // prevents dropped frames in xine vdpau h264
} Play(); }
I can't help the feeling that this is a problem that should be addressed in xine, rather than working around it in VDR.
Klaus
I agree. I just thought, until that happens, it is nice for those concerned to have that patch. And maybe this patch gives an idea for a fix in xine. Joerg
-
Joerg Riechardt -
Klaus Schmidinger -
VDR User