Jörg Knitter a écrit : > Klaus Schmidinger wrote: >> Well, tell that to people writing plugins for such output devices. >> I don't see where *I* would be involved there?! >> > Are there enough interfaces to be able to read the and control the OSD > for including them seamlessly it into a different front-end? I don´t > think that SVDRP and interpreting the returned data is the best way to > go. And what about the limitation on one OSD per VDR? > I think, these are the real limitations - currently users of media > center UIs are exiting them and start xinelib for using VDR and visa verse. > A better separation of "back-end" and "front-end" could IMHO solve the > problem and end the discussion about hardware related support. Because > with a clean and some kind of more standardized interface (which also > transmits OSD related information), you could write every "output device > connector/plug-in" that you can think and be compatible to more > front-ends or devices then before. Even an "evil" Windows front-end with > VDR running on Windows (with the help of something like colinux or a VM) > would be possible. > Currently, xinelib (with original OSD) uses a different protocol than > the VOMP plug-in does (own UI). Then, there is the ffnetdev plug-in > (with OSD tranfered with some kind of VNC IIRC) which also works > different from the streamdev approach (without OSD) that is used for > hardware streaming clients that use oxyl etc. > > Unfortunately, I am just a user, not a developer though I am at least > able to read and modify simple C and script code ;) - it has been a long > time since I was student and was able/had the time to code little > projects...
I second that completely. IMHO, the core VDR should move toward a multiple OSD capability. Maybe the network separation between the back-end and the front-end could just be a compilation setting (add a RPC layer at the correct place, as a compilation option : no layer = current standalone setup; network layer = VDR server + VDR clients). This should provide a clean way to separate the responsibilities between the back-end and the front-ends. The rest is a matter of plug-ins and not over Klaus shoulders. I agree that the hardware side of this is just the visible part (and a good flame-war starter). The plugin architecture allows many things, which is good. The limits of the core makes it hard to create a network-happy VDR system (not a VDR machine, but a system of multiple machines), which is the root of many incompatible and incomplete plugins, solving all part of the problem (xineliboutput, remoteosd, dummydevice, epgsync, remotetimers, etc.) I just recently started using streamdev, for a bare EPIA ML6000 client (diskless, no DVB device, just mobo + RAM + network). I think it's a good (and cheap, silent, power-efficient) starting point for a network-based STB. It's not perfect, but most of the imperfections come from the plugins that must be added and configured, each separately, to achieve a good VDR network STB. It is already possible to have disks array, DVB devices, and all the cables down in the closet, and as many clients we want behind each TV set, with only a CAT5 cable and an IR sensor. That's just difficult. Moving existing plugin code into the VDR core, and getting some out of the core, into plugin, would do a lot in the "right" direction. I trust Klaus to eventually get to it, and the community to provide good plugins, providing a tremendous network STB system. I'm not impatient at all, I know this will happen. The more time it take, the better will be the solution, the longer it will stay. I look at how my neighbours watch TV : DVB-S converted to an analog signal recorded on a crappy VCR, sending wireless scratchy analog to an LCD TV (which was really the top 5 years ago), one tape at a time, no timeshifting, etc. ...and I'm really happy with VDR. -- NH _______________________________________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
