[vdr] Re: DXR3 support patch for vdr-1.1.5

[Malcolm Caldwell <malcolm.caldwell@ntu.edu.au>]

Andreas,

>From looking at the code, it would seem that this path does playback
only?  That is, the OSD is not supported.

BTW: I would say that mess is too strong a word.  Certainly vdr was not
designed for this type of thing - that does not necessarily mean the
code is a mess if you try to use it for something else.


On Tue, 2002-07-23 at 06:39, Andreas Schultz wrote:
> Hi all,
> 
> Yes, it's not an mistake, this is a PATCH for vdr-1.1.5. Welcome back to 
> patching VDR. I tried to find a different way, but the current cDevice, 
> cTransfer and cPlayer architecture does not allow any other solution.
> 
> This release is mainly indented for developers and still has severe 
> limitations, most of which will not go way unless the cDevice mess is clean 
> up.
> 
> Patch is at: http://warp10.net/dvd/plugin-devel/vdr-1.1.5-dxr3-01.diff.bz2
> 
> ffmpeg's libavcodec is need (change the path seeting in Makefile).
> 
> fixable problems:
> - Audio/Video might get out of sync
> 
> unfixable problems:
> 1. only replay works, transfer mode is to deep embeded into cDevice
> 2. primary DVB device will remain blocked during playback, but will not show 
>    anything
> 3. primary DVB device needs to be availabe for replay, cPlayer always needs to 
>    be attached to a cDevice, DXR3 can not be a cDevice

So the class cDevice is not not designed for what you want to do.  That
does not mean it is bad, or a mess.

>From my reading it would seem that this is only a first step toward an
abstract device class that can accommodate different types of
input/output devices.

> Have fun
> 
> 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 (:-))."
-- 
Malcolm Caldwell <malcolm.caldwell@ntu.edu.au>
Northern Territory University