[vdr] Re: VDR developer version 1.1.6

[Andreas Schultz <aschultz@cs.uni-magdeburg.de>]

On Monday 05 August 2002 18:38, Klaus Schmidinger wrote:
> Stefan Huelswitt wrote:
> > On 05 Aug 2002 Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de> wrote:
> > >> The simplest solution would be to allow PlayVideo() to block. Is that
> > >> acceptable? (IMHO it is not)
> > >
> > > See above. PlayVideo() doesn't have to return "immediately", but it
> > > must be fast enough to allow the player to keep up with reading the
> > > data.
> >
> > I think PlayVideo() should return nearly "immediately"
> > (non-blocking) as the player task may need much more CPU
> > power/time do process the read data (e.g. decode MP3,DIVX etc).
> > If PlayVideo() would block, the player may need the old
> > two-thread approach to keep up with the data rate.

/bin/agree

> Sure, that's what I mean, too. The question is just how much time the DXR3
> processing takes. If it doesn't take too long, doing it directly in
> PlayVideo() would probably be acceptable. If it takes too long, the
> cDXR3Device would have to do it in a separate thread.

The main problem is not the processing time or the requirement to parse and 
assemble frame, the problem is the time it might take to send the processed 
data to the device. To do it non-blocking a two stage approach is need (1st 
prepare a larger datablock, 2nd stuff it in small pieces into the device). 
You currently have excactly that implemented in cDvbPlayer. All i suggest is 
to move parts of that two stage process into the device class.

Andreas
-- 
Andreas Schultz <aschultz@cs.uni-magdeburg.de>
Student of computer science

"In accordance with plans for Linux OS world domination
      infiltration of governments is vital (:-))."