Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[vdr] Re: VDR developer version 1.1.6
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
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
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 Schultz <email@example.com>
Student of computer science
"In accordance with plans for Linux OS world domination
infiltration of governments is vital (:-))."
Main Index |