[vdr] Re: Buffer Overflow because of cReceiver-Threads locking each other

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

Rene Bartsch wrote:
> 
> Hi,
> 
> we have the problem (especially with streaming-plugins) that
> cReceiver-threads lock each other if one of them doesn't get data by
> time. Then VDR drops packets (skipped 99 Bytes of TS-stream). But this
> causes invalid MPEG-streams making the player to swallow. In turn the
> cReceiver-threads lock again and drop packets. So we get a never-ending
> story of cReceiver-threads and invalid MPEG-streams locking each other.
> 
> This could be solved by a buffer in the cReceiver-threads, which drops
> the frames up to the next I-Frame in case of buffer overflow (or repeats
> the last I-Frame in case of buffer underruns) making sure the
> MPEG-stream keeps valid.

A cReceiver is supposed to accept the data offered in a call to its
Receive() function _immediately_, and return without any unnecessary
delay. It's the duty of the derived cReceiver class to implement any
kind of buffering it might need.

There was a problem with timeouts in cRingBuffer* in versions before
1.1.31, but that has since been fixed.

Klaus
-- 
_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10
CadSoft Computer GmbH                   Fax:   +49-8635-6989-40
Hofmark 2                               Email:   kls@cadsoft.de
D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de
_______________________________________________________________


-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.