On Tuesday 11 January 2005 19.43, Dirk Meyer wrote:
> A second problem is that xine can't use stdin, we need it
>for controling xine.
There has been some talk about this recently on the xine-devel mailinglist.
And it all depends on the frontend of course.
While xine-ui is great as stand alone
Hi,
let's make it more complicated, just for fun. What should be possible:
I record from 8pm. to 9pm. At 8:15 I start watching the channel. The
correct way would be to start with the recording, but ater 9pm. the
recording should still run, maybe the user wants to watch after the
recording, too. Bu
Dirk Meyer wrote:
Rob Shortt wrote:
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 rece
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
Rob Shortt wrote:
> 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
> r
Dirk Meyer wrote:
Rob Shortt wrote:
Yes, videolan will multicast normal UDB as well as RTP, in adition to
some other methods. I've been taking a look at VLC too, so has Dischi
I believe.
But I'm too stupid vor vlc. I wasn't able to send a file with rtp and
mplayer or xine playing it.
I'm playing
Rob Shortt wrote:
> Yes, videolan will multicast normal UDB as well as RTP, in adition to
> some other methods. I've been taking a look at VLC too, so has Dischi
> I believe.
But I'm too stupid vor vlc. I wasn't able to send a file with rtp and
mplayer or xine playing it.
Dischi
--
I once tho
Hans Meine wrote:
> On Tuesday 11 January 2005 19:43, Dirk Meyer wrote:
>> Since mplayer can't do the #save trick, we need the bmovl part
>> in xine.
> What "#save trick" are you talking about? MPlayer is very well able to save
> any stream it can receive (-dumpstream option, filename configured
Dirk Meyer wrote:
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 m
Gustavo Barbieri wrote:
I don't know videolan internals and if it uses multicast/broadcast,
but they way you want to do reminds me videolan functionality... or am
I wrong?
Yes, videolan will multicast normal UDB as well as RTP, in adition to
some other methods. I've been taking a look at VLC too,
I don't know videolan internals and if it uses multicast/broadcast,
but they way you want to do reminds me videolan functionality... or am
I wrong?
You're really good on this new proposal, freevo will rock!
Cheers,
--
Gustavo Sverzut Barbieri
---
Computer Eng
On Tuesday 11 January 2005 19:43, Dirk Meyer wrote:
> Since mplayer can't do the #save trick, we need the bmovl part
> in xine.
What "#save trick" are you talking about? MPlayer is very well able to save
any stream it can receive (-dumpstream option, filename configured
separately). Is this wha
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
> net
13 matches
Mail list logo
