Rob Shortt wrote: > 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.
Yes, that was the idea. There will be a generic mbus daemon plugin in the recordserver to talk to the daemons. But if someone doesn't like it, the recordserver can also do the stuff it's doing now. We should also support the current solution. > 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. Good. Maybe freevo will get epg data for the channels he will need next before the user switches the guide. > 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. No, rtp has timestamps. We will create some based on the timestaps in the mpg file. RTP is the cleaner solution for sending media data over a network. > 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. You can also use vnc to stream the data. I wasn't able to get running, but it should work. > IMO let the client worry about timeshifting and keep things as > simple as possible. We need people working on clients. Without that, no timeshifting :( Dischi -- Never let a computer know you're in a hurry.
pgpKuyLHtaz77.pgp
Description: PGP signature
