On 26.01.2009 12:10, Udo Richter wrote:
> On 26.01.2009 08:39, Klaus Schmidinger wrote:
>> On 25.01.2009 23:53, Udo Richter wrote:
>>> Attached is a new version of cDevice::PlayTsVideo and
>>> cDevice::PlayTsAudio that properly handles partially accepted buffers of
>>> the PlayVideo and PlayAudio functions. The original functions would
>>> discard any partially written data.
>> By definition these two functions shall write "all or nothing".
>> So the higher level functions needn't handle any partially written data.
>
> But in fact they write all or nothing or timeout after one second, in
> which case they return how much was written. And it seems as if these
> timeouts do happen.
I did some more investigating, and things get really strange...
First, there's no evidence for the 1000ms timeout to actually happen.
Data in fact seems to be written 'all or nothing' in reality. Both
cases, all and nothing, do happen.
The PlayTS functions however are still wrong, since they do not handle
the case where -1/EAGAIN is returned immediately. The PES packet was
returned by GetPes and will not be returned again, so this PES packet
will be dropped.
I also experimented with the VDR-1.7.3 solution again:
do {
w = WriteAllOrNothing(fd_video, Data, Length, 1000, 10);
if (w < 0 && errno == EAGAIN) {
cPoller Poller(fd_video, true);
Poller.Poll(200);
}
} while (w != Length);
WriteAllOrNothing returns either Length or -1/EAGAIN. The poller sleeps
for about 0-20ms each time. CPU load isn't too high either. Still I have
an ARD recording that reproducibly hangs at the same point every time
for a fraction of a second, and only if I use the above loop. This
happens 1-2 times per minute, and usually causes heavy audio/video
desyncing.
The VDR-1.7.1/VDR-1.7.4 version does not show this hang:
return WriteAllOrNothing(fd_video, Data, Length, 1000, 10);
Anyone has an idea what really causes this?
Cheers,
Udo
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
