[vdr] Re: VDR developer version 1.1.6

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

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

What do you mean: the renaming or the definition? Apparently "normal" video
and audio (as, e.g., recorded by VDR from a channel without Dolby Digital)
closely belongs together and should be sent through a common channel (as is the
case with the DVB driver). If a device needs to separate the audio and video data,
it can do so. Dolby Digital on the other hand, as far as I can see, goes quite
different ways. It may have to be piped into an external program, or sent to
an SPDIF interface or whatever. Therefore I'd assume that having a channel
where the player stuffs in the Dolby data, and which, on the other end, has
a plugin-provided cAudio class that knows where to actually send the DD data
should be a feasible way to do this. Or am I missing something important here?

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

The idea is that the player reads the data from the disk and makes sure it
has a decent "reserve" in case the disk is temporarily unavailable. It pushes
the buffered data into the device in the same thread, so the device shouldn't
block too long. However, I guess it should be ok if the device takes "some"
time to process the data. It just has to make sure it leaves the player enough
time to read further data from the disk. I suggest you try processing the data
that comes into your device through the PlayVideo() call and return once you
have completely processed it. If that doesn't result in a smooth replay, either
the machine is too slow or you'll have to implement an extra thread in your
device that does the conversion. You shouldn't have to implement that much
additional buffering, since I assume you'll be converting one frame at a time.

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

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.

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

Wasn't it you who wanted the buffering done in the individual players?
Moving it into the devices would, IMHO, not be the right way to go.
After all, the DVB cards don't need additional buffering (at least not
in user space). If the DXR3 device needs to process the data before
sending it to the hardware, it should do so in its own buffer and, if
necessary, thread. But first I'd try if letting PlayVideo() return after
processing all data works.

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

What if the world ends tomorrow? ;-)

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
_______________________________________________________________