Rob Shortt wrote: > Hi all, I have been thinking a lot lately on how to improve Freevo's > architecture with regard to individual processes and the network.
I guess it's time to create a global freevo 2.0 architecture now.
> 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.
Yes, sounds good.
> 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.
Yes, when we designed the mbus interface for the recordserver we had
three entities in mind: the gui, the recordserver and record
daemons. The later are applications that handle tv cards. Every pc in
the network having a tv card should run such a daemon. The
recordserver can control this daemons. Now the gui wants to record or
watch tv. It sends a request to the recordserver. The server checks
which daemon can/should handle this and starts recording or streaming
on the daemon. So everything in the setup is handled by the
recordserver who knows what to do on what card.
> 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.
Sounds like a good idea.
> 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.
One epg server sounds good, too. We need to make some local caching to
avoid long delays.
> 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.mpeg
Yes and no. When you speak of sending data over multicast, I'm
thinking of rtp. So the record daemon should unpack mpeg-ts (for dvb)
and put it into two rtp streams (video/audio). IIRC both mplayer and
xine can handle rtp.
> There 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
No, doesn't work. The #save stuff only works with rtp. But hey, we
want rtp. A second problem is that xine can't use stdin, we need it
for controling xine.
So what do we need for a simple setup: we need something sending rtp
data over the network. Freevo is only a gui for other programs, but at
this point we need C/C++ programmers writing such a daemon. I know
someobody who started this project for dvb-t. He will need help for
other dvb types and ivtv. I'm not sure how to handle normal analog
cards. Since mplayer can't do the #save trick, we need the bmovl part
in xine. And maybe if people want to help, what about using rtsp to
control the stream to move the timeshifting to the record daemon or a
special timeshifter.
Dischi
--
In the Beginning
It was a nice day.
-- (Terry Pratchett & Neil Gaiman, Good Omens)
pgpIQpg76WIFd.pgp
Description: PGP signature
