[vdr] Re: VDR developer version 1.1.6

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

Andreas Schultz wrote:
> 
> 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.

Actually PlayAudio() is intended for playing _additional_ audio data, like
Dolby Digital. Since I was urged to first implement the cDevice plugin interface
I had to postpone implementing PlayAudio(). PlayVideo() is used for playing the
"normal" A/V data. maybe I should rename PlayVideo() to something like PlayAV(),
and PlayAudio() to PlayDolby()?

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

The device should take A/V data through PlayVideo() and break it apart as
necessary.

> 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.

A call to PlayVideo() doesn't have to guarantee that all data is actually
written. A device's PlayVideo() is free to consume as many bytes of the offered
data as it can "swallow". It's even ok if it decides not to consume any data
at this call. I don't see where the buffer mechanism in the player wouldn't
work for such a device - but maybe I'm missing something important here.

I would expect that a cDXR3Device (or whatever you call it) should be able to
work together with the builtin cDvbPlayer. You should not need a specific player
for that device - otherwise the idea of having player and device plugins would
be somewhat futile. Maybe there are still things that need to be made more
abstract, though.

> 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.

I also don't like the current way of exposing the device's file handle to the player,
but at the time I didn't find a better solution.

I guess what I could do is to introduce a cPlayer::Poll() function, which the
player calls with its own file handle(s). That function in turn calls a virtual
cDevice::Poll() function, which the derived device can re-implement to add its
file handle(s). It then calls the Poll() function of the base cDevice class, which
can then poll all participating file handles in one poll() call.

Would that be something useful?

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
_______________________________________________________________