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);
      } 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 

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?



vdr mailing list

Reply via email to