[vdr] Re: VDR developer version 1.1.6

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

On Monday 05 August 2002 09:47, Klaus Schmidinger wrote:
> 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()?

That opens a whole new can of worms. Lets talk about that in a different 
thread.

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

i guess, i also like it better this way.

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

No you didn't, my explanation wasn't good enough. The buffering will of course 
work and it is actualy not a real problem.

The dxr3 has two properties that do not fit well with the current cDevice 
interface. Both could IMHO be accomodated with some tweaks to the API.
The alternative with the current API would be to introduce additional (non 
trivial) buffering in the device object, which in the spirit of "keep it 
simple" i would really like to avoid!!

On the video side, the card can only play a pure MPEG stream. All PS and/or 
PES headers need to be stripped away. The easiest way to do that, is when the 
device is always being feed with complete PS/PES packets and when it can 
process those packets at its own pace. Otherwise a more complicated 
reassembling of the incoming packets has to happen (which means more buffers 
and more overhead).
VDR's current structure already guarantees that the first call to PlayVideo() 
for a newly read packet will contain a complete PS/PES packet. Subsequent 
calls for the same packet can be avoided by processing the complete packet at 
once. However, we might not be able to actually write the full packet to the 
card at once. The DXR3 device could now simply block and return to the caller 
only once the full packet has been written. But from the API and its usage I 
get the impression that PlayVideo() was not supposed to block, right? Again 
blocking can be avoided by using addional buffering in the device object.

On the audio side, the card can only play PCM audio. The MPEG audio stream 
needs to be decoded, which expands it size. This and the MPEG audio decoder 
expecting full mpeg frames leads to excatly the same problems and solutions 
as above.

The simplest solution would be to allow PlayVideo() to block. Is that 
acceptable? (IMHO it is not)
The other solution, would be to make PlayVideo() always take possesion of the 
complete packet (but do not memcpy() it) and have an additional method do the 
actual non-blocking writting. This would mean, that the buffer mechanism from 
cTransfer::Action() and cDvbPlayer::Action() would be moved into the device 
object.

What do you think?

> 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

definetly!!!

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


What if the player has to wait on something that is not a file handle? Ok, you 
might be doomed anyway in that case ....

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