Re: Video Capture and Streaming Battle Plan (was:Fluendo, DV capture & other bits and pieces)
On Tue, 2005-06-07 at 12:34 -0500, John Lightsey wrote:
(suggestion involving ffmpeg for encoding)
> Since every step after creating the final DV file is automated
> we can focus more attention on editing.
I liked your suggestion. Partially because I am familiar with ffmpeg.
On Tue, 2005-06-07 at 20:27 +1200, Martin Langhoff wrote:
> > 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.
John Lightsey:
> 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.
I'm pretty shy about demo-ing Kino because it is so prone to lock-up!
I don't dare using it for live recording myself; I use dvgrab.
> 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.
Timecode for the start of the talk (Kino shows that) can be appended
to a README. Holding a "slate" in front of the camera for a few seconds
might also be worthwhile.
> 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.
This could work well if the resolution were 1280x720 or more (HDTV).
But it will look crappy with highly compressed 320x240 video.
Especially since the screen is usually brighter than the presenter.
You get a recording with a small, underexposed presenter and a screen
that is often too small to be clearly legible.
I have a recording illustrating the problem of exposure:
<ftp://ftp.skolelinux.no/skolelinux/press/20050520-kopinor/lessig_20050520.mpeg>
Viewing the first couple of minutes will make it clear that the
screen and the speaker could not be shown clearly at the same time.
Either the presenter would get very dark, or the screen would be
very washed out. So the camera must alternate.
To be visually compelling, the camera must frame the speaker
tightly, and anticipate the interest of the audience: It should
start moving towards the screen before the speaker points at it.
If it doesn't, it will get the "surveillance camera look".
I would recommend placing the camera in one of the frontmost
rows, and not on the side. It should not be much above the
eye-level of the speaker.
Conversations can be more engaging than lectures,
and close is more engaging than distant:
http://www.nuug.no/pub/video/published/20050509-doctorow-3min.mpeg
> The camera operators will just need to monitor the equipment and
> let someone know if anything goes wrong.
I think the camera operators should do a little more to make a
recording that is pleasing to watch. That involves zooming in on
the speaker, and using the appropriate zoom on the screen, so that
it can be perfectly legible at low resolution.
I can give a crash course in framing and camera movement, if needed.
> We'll split the files into different talks after the fact.
Are you suggesting _one_ humongous file per day? The filesystem
supports it, but does Kino behave well with 60 GB files? I am afraid
Cinelerra has some scaling issues, too.
--
Herman Robak
--
To unsubscribe, send mail to debconf5-video-unsubscribe@lists.debconf.org.
Reply to: