-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael
One thing you could do is to add some detail to the 'Talk audio recording' and 'Talk audio editing' sections on the http://wiki.europython.eu/VolunteersByActivity page. May be make both section 'Talk audio/video ...'. I was thinking that we should send out another 'volunteers wanted' email on europython-attendees soon and it would be good if there was more detail for people to understand what they were signing up for. All the best. 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/ iD8DBQFMESrf7Z7YaKfan9kRAjJmAKCBJrbFth1SwlszVatu4kaVtyDaSgCfXXF5 Lts+ZZeS9kMKcbA4DE2WHQg= =PD0Q -----END PGP SIGNATURE----- _______________________________________________ Europython-improve mailing list [email protected] http://mail.python.org/mailman/listinfo/europython-improve
