[vdr] Re: VDR developer version 1.1.6

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

On Sunday 04 August 2002 18:16, Andreas Schultz wrote:

[...]

> or will it stay the way it is?
> 2. Attach() stuffs a single fd into the player class. This fd is used to
> determin wether we can write to the card or not. This will no be enough for
> a DXR3 card which would need 2 or 3 fd's. However, i would prefer a
> solution that is more flexible and could also handle non-fd based busy
> checks transparently. Do you plan something in this direction?

I think this needs a bit more clarification.

Currently the method implemented for playing video and audio is PlayVideo(). 
PlayVideo() is sending the data through one fd to the card. This fd is also 
beeing used in the player class to pool() on them. PlayAudio() is there but 
not implemented.
On the DXR3 card audio and video needs to be send though different fd's. Also 
audio and video data needs to be processed in between. That creates a couple 
of problems:
1. either, audio and video is beeing sent through the appropriate Play.... 
methods or the device class has to parse and seperate the video and audio 
streams internaly (this is not problem, just a design decision)
2. Two fd' needs to be checked by the player
3. PlayVideo does not gurantee that all data is beeing written to the card and 
the buffer and timeout handling is done in the player class. For the DXR3 
that does not hold true. Buffering and _processing_ needs to be done in the 
device class. Therefore the buffer mechanism in the player class can not 
longer work as intended.

I believe that a generic solution that does not involve exposing device fd's 
to player classes would be best to solve 2 and 3.

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 (:-))."