Re: Video Capture and Streaming Battle Plan (was:Fluendo, DV capture & other bits and pieces)
On 6/8/05, John Lightsey <lightsey@debian.org> wrote:
> I'll write a perl script to process the DV and move it between IN, OUT,
> and DONE directories. The only think I don't know is how files will
> move from the encoding server to the web server. rsync running from
> cron?
Yep, rsync on cron, reniced. With a means of doublechecking that it
made it to the server (md5sums?) and removing it from the encoding box
-- because I doubt the encoding box will have enough HD space go get
through one day ;-)
We'll also want to do the same with the encoded files.
> > > 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.
> >
> > You mean stop on the camera? We'll never do that ;-) we never
> > start/stop on the camera itself. All we do is have it on. Or you mean
> > "stop" in the Kino UI? Might need to test with the cameras we have.
> >
>
> The stop button in kino locks things up during live capture for me.
Does it happen every time? What camera/fw card/kernel?
> > > We'll split the files into different talks
> > > after the fact. The operators will leave them running continuosly.
> >
> > The "live streams" will run continuosly, but the DV captures should
> > definitely be started/stopped and the files names with the
> > presentation title/speaker.
> >
>
> Are there going to be gaps between presentation big enough to make this
> important? If there are only 5 or 10 minutes between presentations, the
> cameras might as well run the whole way through the day.
The gaps are considerable and the stop/start is the time where the
camera operator names the files ;-) The operator is there, and can do
that level of labelling -- useful to keep the operator involved,,
checking sound level, etc.
And having the files split and labelled per-talk is a boon at edit
time. Imagine scrubbing though 5hs of video to find where a given talk
starts. Argh.
(kino/dbgrab will rotate the files but keep the name prefix)
> I'm assuming that no one is going to be processing video while the talks
> are taking place (they'll either be filming or attending) and that each
> camera has a single large USB drive. At the end of the day the drives
> are taken to the hacklab and individual presentations are chopped out
> with kino then uploaded to the encoding server which encodes them with
> FFMPEG and uploads them to the web server.
How can we minimize the human time involved? At that stage, we _will_
have the theora-ogg stream already encoded -- perhaps some minimal
splits and joins, as the theora-ogg files will be rolled at arbitrary
times?
BTW: consider that I'm not sure whether we'll have high-end
workstations for editing quickly. Last debconf, all the high-end gear
was being used to build heavy packages (the Openoffice gang was hard
at work, cranking packages out like crazy -- and each recompile took
ages).
The last thing I want is to force several hours of work each evening
upon us. It's enough with the camera operation -- I'll do some too --
setting up and monitoring all the infrastructure and process. We must
do some labelling and uploading at the end of the day, granted.
But editing and compressing at the end of the day sounds like a
multi-hour trick -- I want it fast, like a quick "split/join the
theora files to get one talk and add a title still" with a tool that
can do straight-cut edit but doesn't recompress. So we'll be done in
20 minutes and back to hacking and schmoozing with other Debconf
attendees ;)
(lazy!)
> Actually, now that I'm thinking about it again, it would greatly
> simplify the process if the camera operators did the cutting on the
> spot, as you are suggesting, and we simply copied from the USB drives to
> the encoding server.
Checkout my original plan -- why would we need to do it with USB
drives when LAN is fast? and the capture boxes _will_ be doing
encoding on the fly.
> Does this sound reasonable?
Hmm, I'm not sure if you didn't read my proposed plan or perhaps you
found problems with it. If you found problems with it, tell me -- in a
non-LAN and not encoding at the capture box in realtime, yes, your
plan is great. But it requires a lot more manual work -- which I want
to avoid.
Camera operation will need manual work, that's unavoidable, so I want
to make it interesting somehow ;-) -- everything else I hope to
streamline as much as possible.
cheers,
martin
--
To unsubscribe, send mail to debconf5-video-unsubscribe@lists.debconf.org.
Reply to: