Re: quo vadis, video team ?!
I don't think I'll be able to join. A brief update on things at my end:
I am still working on the Flumotion track, it's going well --- I will
soon be preparing some theora-mmx packages. I tried to get flumotion
running ok on Sarge or on Sid, but it's been an enomous timesink.
Flumotion needs a toolchain based on Python 2.4 and our freeze caught
us with a good 2.3 toochain.
My early testing had been on Ubuntu-Hoary and I was hopign to backport
a few things, but it's too big a job for this non-python guy. (Happy
to port Perl sh*t around, but I just don't know enough python). My
conclusion has been that the flumotion infrastructure should be
Ubuntu, and that's ok with me.
As soon as the Python toolchain moves forward on Sid/Etch, flumotion
will fall into place. But we have big fish to fry *now*.
We need x86 CPUs around 2GHz for flumotion video capture and encoding.
With a properly tuned kernel, 2GHz works pretty well for capture too
(kino/dvgrab). I have good kernel config files we can use with 2.6.12
kernels. The fluendo guys have offered to help me add a flumotion
module to store the hi quality DV stream on the capture box as we are
streaming -- we shouldn't need to run Kino and Flumotion at the same
time (and I don't think both together will be happy on mid-spec
laptop).
Now, I've seen the network notes mentioning that we won't have
reachable IP addresses from the outside. That's just fine -- if we
want to stream the videos anyway, we can always push them out to a
publicly reachable host. Flumotion components just pipe into one
another and do "netcat" style pipes across the network transparently.
I'll have a cheap Sony camera with me, as well as a FW/USB 60GB
drive-- but we shouldn't need to use the drives sneakernet style. The
laptops have network, right?
cheers,
martin
--
To unsubscribe, send mail to debconf5-video-unsubscribe@lists.debconf.org.
Reply to: