Hi All,
This is a little bit stream of conciousness, but feedback &
volunteering to help is welcome. Part of the reason for sending this
is sanity checking as well. If you spot a gruesome error, or think
I've missed something please don't think "oh, I'm sure someone will
mention that or he doesn't really mean that" - please tell me.
Last year I recorded lots of Europython talks as can be seen here:
* http://mail.python.org/pipermail/europython/2009-July/007488.html
This year I'm intending to do the same thing as last year, but John
has mentioned the availability of 3 cameras similar to (but not the
same as) the camera I was using last year.
>From a recording perspective, the primary difference appears to be
that the optical zoom level is lower (5x rather than 10x), and I've
been thinking about how to best organise things.
Having the talk schedule, especially including rooms to be used,
available now really helps, and my suggestion would be this:
The 3 5x cameras get used for recording talks in Recital Hall, New
Lecture Theatre and Library Theatre. My assumption here is that the
5x cameras can run with of DC power adapter rather than their internal
batteries (I've not got one which is the appropriate model to test
with).
The camera I used last year (10x) is used for the talks in the Adrian
Boult Hall.
The reasoning is relatively simple. When recording the Adrian Boult,
it turns out that recording from the back of the room, with the
optical zoom near maximum gives a better picture angle than recording
near the front.
Compare:
* http://europython09.blip.tv/file/2338504
With:
* http://europython09.blip.tv/file/2338824
For that to make sense, I have to work on the assumption that like
last year the speakers in the Adrian Boult will mic'd up and amplified
through the speakers in the room.
In the smaller rooms, this is less of an issue, and the angle is fine
from the front.
Also, in order to get a decent quality last year I was recording at
relatively hi resolution (4GB per hour), and then transcoding down for
upload to blip. (this meant that I could check that slides & text were
readable before doing so). This works fine, and I think is the best
approach. What I wasn't aware of until just before last year is that
this would leave me swapping SD cards all week. (Since copying off the
data does take significant time)
In order for this to work with 4 cameras, we really ought to work on
the basis that the cameras should be "emptied" at lunchtime and
evening. For that to make sense, that suggests 3 hours recording in
the morning, and 4 hours in the afternoon (being approximate). Taking
the higher of these, that would suggest each 1/2 day session would
require 16GB SD card. (to be on the safe side).
So 4 cameras, 4 x 16GB SD cards.
Since copying off 64GB during lunchtime seems unrealistic, it seems
more reasonable to assume a morning set, afternoon set, and "swap
set".
That suggests we need 12 x 16GB SD card. However, the cheapest for
that that I can find is about 23GBP each. That gets things into silly
amounts of money.
Incidentally, yes, you can go to a lower bit rate, but starting off at
4GB/hour is reasonable, since if someone uses a rediculously small
font in their slides, you'll capture it.
As a result, to me that suggest a handful of alternatives:
* Just record at a lower data rate. This comes at the price of capture
resolution however. That's suboptimal to say the least. (I'd rather have
a lower q value than resolution, but you can't change that in camera)
* We need more volunteers for hotswap data copying.
* Can we get anyone's employer to loan a dozen (or more) 16GB SD cards. (I
can explore that option)
If we can go down this route of a dozen SD cards and the various
cameras then the way this would work is as follows:
At the start of the day:
* The 3 5x cameras would be mounted on tripods at the front of the 3
smaller rooms. They would be plugged into DC adapters for power.
* The 1 10x camera would be mounted on a tripod at the rear of the room.
They would be plugged into DC adapters for power.
* An empty 16 GB SD card would be put into each camera.
* The cameras would be pointed in the right direction, and then the record
button hit. The session chair would be asked to keep an eye on the
camera to ensure the camera isn't nicked (!)
At the start of lunchtime:
* The SD cards would be collected, and swapped out. It would probably be
wise for the cameras themselves to be collected in fact, unless someone
was going to stay in the room.
At the end of lunchtime:
* An empty 16 GB SD card would be put into each camera.
* Camera orientation would be checked, and record button hit.
At the end of the day:
* The SD cards would be collected, and swapped out, and the cameras
returned for safe storage.
In the meantime in the afternoon the SD cards would be copied off onto
a large HD, and the same in the evening. If possible, transcoding
would be started overnight, but since the files are large, to avoid
hammering the upload connection at the conference, the videos would be
uploaded to blip AFTER the conference.
For reference, last year I was carrying a camera, tripod, laptop,
external high capacity drive, and 4 way extension (for various
adapters involved) between sessions, setting up and whilst the
sessions were going hot swapping a handful of 4GB SD cards between
camera and laptop, hastily copying their contents on to the high
capacity drive. This was pretty intensive work throughout the
conference, but worth it IMO. It did however mean that talks longer
than an hour caused issues.
Tweaks to this to assist with editting may include asking the session
chairs to simply place their hand infront of the camera for a second
or 3 to make it easy to find breaks between sessions. (I can automate
it if that gets done reliably)
Clearly this all becomes a lot easier if there are volunteers willing
to step forward and help... If there aren't this seems a starting
point.
Just to recap though, the question I have at present regards the dozen
16GB SD cards this approach seems to need.
The options available here are:
* Just record at a lower data rate. This comes at the price of capture
resolution however. That's suboptimal to say the least. (I'd rather have
a lower q value than resolution, but you can't change that in camera)
* We need more volunteers for hotswap data copying.
* Can we get anyone's employer to loan a dozen (or more) 16GB SD cards. (I
can explore that option)
Comments, suggestion welcome. (flames not :-)
Regards,
Michael.
[
For the video geeks out there wondering why 4GB/hour, the reason is
simple - in order to capture the speaker and slides effectively, I
need to capture at a high resolution.
Video cameras tend to want to impress so they tend to have a fixed
quality setting, and as a result won't let you play with things like
GOP values or q'values (times between reference frames, how much
motion is degraded (ish), and how well edges are handled a really for
those who don't know video). Capturing talks with slides on video
means that we need to capture text, which means we need hi res, but
can cope with the text taking a moment to settle. The camera doesn't
know that so says "if you need hi res, it costs this amount of bit
rate" essentially. By capturing at 4GB/hour and transcoding
afterwards, I'm essentially can tweaking that balance.
The downside is it costs space or volunteer effort. As a resu
]
_______________________________________________
Europython-improve mailing list
[email protected]
http://mail.python.org/mailman/listinfo/europython-improve
