On Wed, Jan 31, 2007 at 08:38:29PM +0100, Klaus Schmidinger wrote:
> > From what he's saying, the problem is buffer overrun's, not underrun's.
> > Too much data is being sent and the device isn't able to keep up. If
> > that's the case then it would make sense for vdr to have a user setting
> > to limit how many seconds (or milliseconds perhaps?) worth of data is
> > sent to the buffer. I can't think of any reason not to add such a
> > feature if it means better usability for the end-user.
>
> If the device can't take any more data, it should just refuse to
> accept it and return from the write() call without anything written.
I gather that in plugin-based playback, cDevice::PlayAudio() and
cDevice::PlayVideo() are overridden and may return 0 to indicate
that nothing was written.
I modified PlayAudio and PlayVideo in softdevice.c so that they return 0
when softdevice is in suspended state. That is, I replaced
if (! packetMode)
with
if (!packetMode && !setupStore.shouldSuspend)
in both methods, so that they would return 0.
This seemed to work for recordings, but I am not sure if it worked for video.
If I suspended the playback for only a short while, it looked like the
playback resumed from where it was stopped, and maybe some frames were
dropped every now and then to reduce the lag. I'd prefer the live
playback to resume without any lag, that is, to drop all live PES packets
during the time the playback was suspended in the plugin. However,
the PES packets from recordings should be blocked.
I believe that the easy fix would be to have these methods return 0 only
when playing a recording. Can the plugin detect this somehow?
Marko
_______________________________________________
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
