[vdr] Re: VDR developer version 1.1.6

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

Andreas Schultz wrote:
> 
> ...
> YESSSSS (but you might not like it)!
> I also want to send non-DD audio from recordings and live non-DD audio to some
> external destination. Basicly the cAudio plugin should _always_ and in all
> operation modes (even in live TV mode) receive the best quality audio
> available, if that happens to be only MPEG2 audio, than be it.

I suggest we first try to get the basic cPlayer/cDevice stuff up and running
and cross the "external audio" bridge when we reach it.

> ...
> > 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
> 
> There are actually two distinct and different buffers in cDvbPlayer. You have
> the ringbuffer, that builds the reserve you are speaking of, and you have the
> block of memory (usualy one frame) that you are trying to write to the
> device. I am refering _only_ to the later.

"Usually one frame" - but that's by no means defined or required. The device
should make no assumptions as to the size of data blocks. The player delivers
chunks of data which, put together, form the complete audio/video data stream.
It is at the discretion of the player to decide what size blocks it sends to the
device. The fact that in the cDvbPlayer this happens to be a complete frame
does not mean other players have to do the same, since that would require
every player to eventually parse the stream to find the frame borders.

Having said that, if a device needs to identify complete frames it has
to gather enough data to do so. It can't expect the player to make sure
it sends a complete frame each time it calls PlayVideo().

> > 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.
> 
> I do have to copy the entire frame then. This might not be much (in the great
> fabric of space and time) but i think we should avoid unneeded copies as much
> as possible.
> The copying can be avoided (see below ...), if I can take posession of the
> frame that the player wants to send to the device and only inform the player
> about my progress. All this can be done without to much modification to the
> current code and without additional threads.

Have you even tried yet whether doing the whole processing in PlayVideo()
would work? Just set up a local audio and video buffer, copy the data that
comes in into these and, as soon as you have enough data, process it and
copy it to your devices.

> ...
> > 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.
> 
> The semantics for PlayVideo I would prefer is:
> 
> class cDevice {
>    ...
> public:
>     void PlayVideo(uint8_t buf, int length);
>     int ProcessBuffer();
>    ...
> };
> 
> PlayVideo(...) will take the entire buffer and store a pointer to it internaly
> ProcessBuffer(...) will send as much data as possible to the device, return
> values:
>   > 0 mean there is still data in the buffer
>   < 0 mean there is still data left, but the device is busy at the moment -
>      try again
>    0 means all data has been written to the card,
> 
> values > 0 do not have to represent the actual amount of data beeing written
> 
> This will eventualy break the poll() on the devices, but i believe you can
> live without that quite happily. The DVB device buffers at least 300 ms worth
> of data (probably more). Checking the device on negative returns from
> ProcessBuffer() every 10ms will therefore still be sufficient.

This would mean that the player has to ensure that it always sends an entire frame,
which I wouldn't want to make a requirement.

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
_______________________________________________________________