Great writeup.
On Tue, 2005-06-07 at 20:27 +1200, Martin Langhoff wrote:
> The DV capture strategy
> -----------------------
> We will capture to HD. We will consume 78GB each day, assuming 5hs of
> presentations @ 13G p/h. We will have a storage server with more than
> 1.6TB of space and Gigabit Ethernet between the storage server and the
> encboxen. Even with Gb ethernet, we don't have enough bandwidth for 3
> full DV streams -- and it'd be really brittle, LAN file storage isn't
> meant for realtime stuff.
>
> Transfer the captured videos will be transferred to the storage server
> with a combination of network transfer (whatever the server offers,
> NFS/SMB/FTP) and FW drive enclosures (which is faster). My estimate is
> that transferring the captures from the 3 cameras (15hs video)
> saturates a Gb link for a bit more than 15hs.
>
> These transfers can be ideally automated. If they aren't too
> burdensome, and we can automate with tools that do smart error
> recovery (rsync for instance) we can run them while other captures are
> happening, reniced to hell.
>
> Camera operation and tools: for direct to HD capture, nothing beats
> Kino. If does what dvgrab does, and will do rotation of files every
> X-time or X-filesize (we can start the LAN transfer as soon as the
> file is rotated). It has a good GUI, and shows the video being
> captured, and I think we can get it to show the sound levels. It has a
> big {record} button and a bit {stop} button. It even gives half-decent
> error msgs if something goes wrong.
>
I've been thinking about the encoding part quite a bit and I'll have
some samples up in the next day or so for testing, but I have one minor
change I'd suggest.
Once the video is captured and moved to an editing PC, we'll use kino to
chop it at the start/end and export it back out as Quicktime DV. At the
same time we grab a frame from the video as a jpeg image.
The Quicktime DV file and jpeg image are loaded onto a beefy encoding
machine which uses FFMPEG to make high quality and low quality XviD
files. The encoding machine will also create an asx file for each avi,
resize the jpeg, and upload the XviD, asx, and jpeg to a server. The
server will have a simple CGI script to create HTML based on the content
that has been uploaded.
Here's why I'm thinking this is a better solution:
Everything we need is already in Debian.
The time spent spent sitting in front of a computer waiting for encoding
to finish is minimized.
FFMPEG works much faster from the command line than it does from inside
kino. FFMPEG will also give us the most bang for the buck on the
quad-cpu machine.
XviD is reasonably free (Debian Main will encode and play it) and well
supported.
If the encoding process gets backed up we can leave it running
unattended during the night to pick up the slack.
Since every step after creating the final DV file is automated we can
focus more attention on editing.
> We will need to add instructions for camera operators to name the
> files they are capturing according to the talk -- but that's as hard
> as it gets.
Some cameras will lock up Kino if you're capturing live and hit the stop
button. You need to turn the power on the camera off first. It would
be nice if they could keep a list of who was talking, what time it
began, and what the title of the talk was.
Since we're not using two cameras per talk we can focus the cameras so
that presenter and screen are both visable at the same time. The camera
operators will just need to monitor the equipment and let someone know
if anything goes wrong. We'll split the files into different talks
after the fact. The operators will leave them running continuosly.
> Realtime compression and streaming strategy
> -------------------------------------------
>
Any chance you can set up a live stream during the next IRC meeting?
>
> The only tricky part is that Theora as packaged is pretty much useless
> for real time encoding. We will need a hand-compiled (or packaged)
> theora-mmx for realtime encoding. Unfortunately my fw box is a PPC (I
> had the privilege of finding all sorts of strange Fluendo bugs on PPC)
> so I haven't been able to build and benchmark theora-mmx.
>
Much of kino seems to be broken on PPC also.
John
Attachment:
signature.asc
Description: This is a digitally signed message part