Hi all, I have been thinking a lot lately on how to improve Freevo's architecture with regard to individual processes and the network.
One of my goals is to be able to run multiple thin clients on the network which are able to view and timeshift live tv, other media, and have full program guide support. First, here's a diagram I whipped up to visualize this proposed architecture:
http://freevo.sourceforge.net/freevo_arch.png
Viewing or recording TV:
I have been experimenting with multicasting video over the network and I am pleased with the results so far. I have come up with an application that can send and receive data over multicast. To send data it reads stdin and writes to the multicast group, to receive it reads from the multicast group and writes to stdout. It can be found in CVS:
http://cvs.sourceforge.net/viewcvs.py/freevo/freevo/WIP/RobShortt/multicast.c?rev=1.1&view=auto
How would we use this? Well, there could be a single process who's responsability is to handle each device (dvbX/ivtvX/tvX). Much like the current recordserver it would have plugins specific to each device but instead of saving the data to a file it would use multicast to send it over the LAN. This process would be on the MBUS and would have an interface to:
-start streaming a device
-change the channel of a currently streaming device
-identify clients and know the priority of each
-use client's priority to allow or disallow channel changing
-use client's priority to withold the multicast address of any device as a level of privacy
Using multicast, and given Freevo client would be responsible for its own timeshifting - people in two rooms could be watching the same thing but at different points in the stream, all while recordserver is recording.
The recordserver would simply tell the device handling process to start streaming a device on a particular channel, then reading the stream and writing it to disk. Recordserver may have higher priority than other clients so noone changes the channel during a recording. Other clients could still watch or timeshift what is currently recording.
The EPG:
Right now Freevo directly uses pyepg for the guide. This means that each Freevo instance needs its own copy of the guide database (on that machine) and would also have to run its own tv_grab, etc. That is not good for a distributed architecture. To remedy this we could have a single EPG serving process on the MBUS that has its own instance of pyepg.
I have a rough draft of an epgserver (and client) that does this. This actually extends some pyepg objects and overrides some functions in order to get EPG data over MBUS. The server interface is minimal and really only covers how we want to access guide data. This draft is very rough and really only done as proof of concept. It does work though and it I am using it on a Freevo frontent in my office.
So, each process in Freevo that needs the EPG can get it from a single souce.
More on timeshifting:
Of course timeshifting tv is still a major work in progress but reading from multicast can be done with mplayer or xine. In my testing I am using ivtv:
on backend: cat /dev/video | multicast -s
on any machine: multicast -r | mplayer -
or: multicast -r | xine stdin://
or: multicast -r > /path/to/recordings/tv_show.mpegThere is an input plugin in xine that will let you save a stream to a local file, enabling you to pause, go back, forward, etc - timeshifting. We could do something like:
multicast -r | xine stdin://#save:/path/to/buffer.mpeg
I haven't been able to test that yet but if it doesn't quite work then maybe we can fix it up to do what we'd like. I know there is enough timeshifting code in xine (input_pvr for example) that we could make an independant timeshifting layer.
There is also Tack's implimentation of timeshifting in mplayer which does work, maybe with slight timing issues in channel changing, not sure... Anyhow, we are getting closer.
I wanted to get this out there and see what your opinions and concerns are about it. I could have forgotten something and will clarify if I can. I really think these changes (or similar) will improve things!
Thanks! -Rob
------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Freevo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freevo-devel
