Rob Shortt wrote:
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.
Ok, I was thinking the process that controls the devices should hold all the logic to decide whick device does the streaming. I was also thinking it would be good for other servers like that to join the bus to provide more devices.
So what you are saying is that there's one recordserver and _any_ number of daemons (each controlling devices on one machine) can join the bus. The recordserver is the one who decides which daemon does the streaming (based on priorities and other stuff), and it can then tell its client (Freevo main, a desktop client, or itself to record) which ip/port to get the data or RTP stream on. Is that correct? If so then I think that's a good design.
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.
Yes, delays are annoying. In my rough implimentation there are some delays on initially fetching the data before it is cached. I need to work on the code some more to resolve this. When I have a chance I'll start a new thread about it.
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.
I need to read up on RTP to see what advantages that would provide. Also why is it neccessary to have seperate streams for audio and video, the client would have to put them together again... that may be creating too much work and asking for a/v sync problems. Using plain old multicast to send an existing stream based format (mpeg1, mpeg2 ps/ts/pes, nuv) causes no overhead and no worry about messing with a/v sync.
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.
Ok, we need to do some testing I guess. Maybe setup a VLC server to stream for testing with various clients. Also using stdin for control slipped my mind, but as you also mentioned we could use fifos. Lets see how RTP feels though.
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
Right, maybe test with VLC.
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
We should use plugins like we do now to record different types. For ivtv all we need (and use now) is the encoder utility that comes with the drivers. I have sent in a couple patches which are in the latest releases and am going to write one for outputting mpeg to stdout as well.
I also use VDR for my source of DVB and by interfacing to it I can produce an mpeg stream for Freevo to use. Same thing for analog cards using mencoder.
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.
I really think any timeshifting should be done on the client side, and that the stream should be multicast (UDP or RTP). Think of the scenario with people in different rooms. The server should only be sending one stream per device too, but it the server does the timeshifting then it will have to send multiple streams, if recording is happening at the same time it gets more complicated. IMO let the client worry about timeshifting and keep things as simple as possible.
-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
