-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 May be we could try to get volunteers to cover the sessions in the same way as we do the session chairs. So we could set up a table on the wiki and ask people to volunteer to cover AM or PM for each room.
If we can get each session covered it would then be a matter of getting the instructions written down so that they can be followed with as little training as possible. Perhaps we could prepare some simple cue-cards that can be kept with the cameras so that someone could do it at short notice with out needing you to show them what is required. If we could get more than 1 external HD we could could speed up the transfer from the SD cards so that it might be doable over lunch. A bank of 4 laptops each with a external HD, or may be a small NAS or a switch, feeding everything into one machine. I don't have access to SD cards - so I can't help there. I would certainly volunteer to cover some of the sessions (especially those that I was chairing). Richard On 09/06/2010 18:38, Michael Sparks wrote: > 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 > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFMD+E57Z7YaKfan9kRAmq6AJ9LjrU4ZFq0RsGGPi5149/KIcv7mACgyVtO wG7T0P/5A1CpSP0avrrZOxw= =CQQV -----END PGP SIGNATURE----- _______________________________________________ Europython-improve mailing list [email protected] http://mail.python.org/mailman/listinfo/europython-improve
