[Openpvr-devel] OpenPVR Architecture

[James O. <jf...@fu...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

After a lot of thinking and a lot of playing around with various things I 
think I can better propose an overall architecture. I encourage anybody to 
critcise, flame, or what have you. Discussion is a good thing.

OpenPVR Daemon:

This basically allows anything to talk to anything and handles scheduling. In 
more detail:

- - API: A single interface to pretty much anything available in the daemon 
itself and in the other components (acting as a proxy). This API can be 
accessed programmatically, from the command-line, and through a web 
interface. Think a cross between 'xawtv-remote' and KDE2's 'dcop' command. I 
recommend reading 
http://developer.kde.org/documentation/tutorials/automation/index.html 
(scroll down to the 'DCOP Interfaces' heading to see it in action)

- - Events: Anything executed on or in the daemon will generate an event to 
which you can attach other API calls. This can be used to easily define 
behaviour. Here's a theoretical example:

"A 'change channel' event is created and set to occur whenever 
'tv.channelup', 'tv.channeldown', or 'tv.channelset' are executed. The event 
is also set to execute 'osd.displaycurrentprogram' so that the current 
program information is displayed."

- - Preferences: These can be stored in a database and may be read or set 
through the API. These preferences may include: program scores (good, bad, 
okay, kinda cool, if there's nothing else on), topic scores, genre scores, 
channel scores, desired recording quality, or anything else

- - Scheduling: Any internal or external process can be scheduled. This is most 
important for recording shows, changing channels, or downloading program 
data. These schedules can be set by events or directly through the API (from 
an on-screen or web-based interface)

I've been playing with a few ways to create this and it looks like the 
Twisted Framework at http://twistedmatrix.com/ is my favourite at this point 
because it's easy to develop with, can be modified on the fly, and 
automatically saves it's state upon exit. The state saving is perfect for 
something like this. It's quite reminiscent of the factory machine design I 
used to do in a previous life as an embedded developer.

I should note that my use of Python here is for prototyping. Changes can be 
quickly made and the architecture can be thought through fully before porting 
to something like C (boo) or C++ (yay). Of course, if it works adequately 
enough for everyone, it can stay in it's prototype form...


Media Player Daemon:

This is basically a wrapper for your favourite media player so that the main 
daemon can play anything at any time (at the user's request, of course).

I created a program that runs continuously and wraps Mplayer. After *a lot* 
of screwing around, I've found that control should be done through a 'fake' 
LIRC daemon. You can use X events, but they don't work on the framebuffer.

Of course, Mplayer could be it's own daemon in the future, but this works for 
now.

I haven't played with GStreamer yet as I have to upgrade to ALSA 0.9, which 
means I'll have to recompile a ton of other software. I'm not exactly looking 
forward to that as I'm a total RPM fiend and that's a *lot* of RPMs:

rpm -q --whatrequires libasound.so.1 | wc -l
     79

That includes KDE, which takes a day or two to compile/package...

- From what I see, GStreamer is most likely a *much* better fit for this 
project, though. I think I'll set it all up this weekend.


LIRC (remote control interface):

It's probably best to let lircd send remote control events to the OpenPVR 
daemon which can process them appropriately (thumbs up/thumbs down, for 
example) and proxy them to applications that already support LIRC such as 
Mplayer. This requires some minor hacking of lircd but can save the hacking 
of individual applications later. This we only have to do once.

This is what I've been playing with tonight. I'm thinking of creating a fake 
remote control driver. The interface seems simple enough. (famous last words)


V4L:

A thin wrapper for v4lctl, in the main daemon. See 'man v4lctl' for more 
details.


Recorder:

This is pretty straight forward. Set the channel via V4L and record it. For 
each program recorded, a corresponding XML metadata file is created 
containing the XMLTV data.


OSD:

The on screen stuff is probably the hardest part, but it looks like GStreamer 
can do a lot of the heavy lifting (overlaying onto live video).

What we want the OSD to display:

- - Program/channel info
- - User interface, widgets and all
- - Setup/preferences

Of course, it'll have to be themeable.


That's all I can think of right now, as it's late and I have to get to bed at 
some point.

Do remember that this is up for discussion and is in *no way* set in stone. 
If you think I'm on crack, then by all means, tell me.

- --
James Oakley
jf...@fu...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8R6sOKtn0F7+/lLMRAiKmAJ4kKhdyNze2+Y2VqEDXpAeLSjFFsgCdGp7g
sRVpAIhJqpKJT0Ls1hgsdzU=
=j/F2
-----END PGP SIGNATURE-----