DebConf5VideoLearnings

Things learning while setting up and doing DebConf5Video and DebConf5VideoVolunteerCoordination - started by HenningSprang - any member of the video team is encouraged to complete this collection.

In the course of creating the videos for debconf5, it seems (we are still on it) like we will get nice results in the end.

But there where minor and major troubles until it was halfways sure that we'll ever achieve that. Here's a list of things that we learned from this funny as well as work intensive experience:

• Persons should not take on too many roles at a time (e.g. infrastructure+ videoteam leader is too much, video volunteer coordinator+audio mixer also). Additional comment: even if you think, for example as the volunteer coordinator, that everything is setup so fine and nicely and running fine, that you can take on another additional job, cause you want to do at least once something else than just making plans, writing up docs, editing spreadsheats - just DON'T! when you try, lots of things will fail at the same time... :)

• you need working contacts to the network infrastructure people so you can really make sure that you have every network access and permission needed to do your work ( we nearly had, and that was good luck!)

• you need a well working communication protocol established, desirably before the event (can we rely on everybody reading their email on a daily or even more often basis? nope, we can't :) -so it doesn't help much if everybody's on the mailing list)

• • handing out plans personally is the most secure way of all
  • a central wiki page is very nice, also (therefore the plan need to be made, or exported in wiki format)
  • sending daily plan documents by mail will bring you in versioning trouble!

• need to publish plans for the next day soon enough so people get informed
• having a machine-readable schedule format is very deisrable, especially for parsing schedule updates
• requirements for talk presentation notebooks should be specified clearly, in time (do we need vga or tv output? can the gardware do that, with Linux?)
• if yout tell the speaker that there are presentation notebooks, they should be really there, one for each room, even one spare one is desireable, and you should not throw away their power supllies
• when working with volunteers, and not exclusively with a clearly defined and trained team, you need a database or spreadsheets with talks, roles of technicians needed for recording each talk, people able to fit in these roles, talks when they do the training for these roles, in adition you have the roles for doing the initial setup in each auditory every day, and probably a troubleshooter role, as well as a role for people eventually doing the editing/postprocessing of the video
• this database should be able to create some printed output,output in wiki format, or be accessible diredctly via www
• Having the volunteer schedule available to participants in iCal format might be a good idea. This would mean that all volunteers could subscribe to the calendar, and the coordinator could update it in place.
• it's absolutely prefereable of all those things are tested some time before the real production starts -you might need some time to fix problems that may occur, as people and information needed for the fix might not be availabe immediately
• we hadn't, but live streaming is a nice and cool thing to add on, even when only for playing with the technology. You need machines able to cope with the estimated requests, and those machines must be accessible from the big bad internet, on the ports needed by the streaming server you chose to use. In case they're not, you need a server on the Internet being able to act as a proxy, you must only be able to send one stream to this machine, it takes care for the real user requests. For sure, the port to send data to the proxy should be open :)
• it's a good idea to collect the presentation slides as soon as possible, that means in advance is a good idea, getting speakers not to leave the room after the talk without leaving their slide is highly recommend, as once their gone, the probability that you'll never see the slides again without some effort might be high :)
• the speakers should be asked as long as possible in advance if they have any special requirements for their talk (e.g. need of 2 projectors), those things also need to be planned and tested ahead of time
• it's not only sufficient to have powerful hardware for the video stuff, it must be configured correctly so it's power can be used,and this should be checked, like always,in advance:
  • known working drivers for accelaration hardware
  • disk tuning (hdparm)
  • correct x drivers
  • finally: can we really record and play videos in the desired resolution and frame rate, with th cameras/inputs to be used?

• it's useful to figure out a server and efficient configuration/software setup for uploading the videos to their desired location, and having a nice way for users to download videos,see information about the talks and having the slides in the same place
• store meta information about the videos at recording time is nice, like we found it a good idea to create a readme file for each video file, named like

<VIDEOFILENAME>-readme.txt. It should contain something like

• • speaker
  • topic
  • room in which it took place
  • event name ( in case videos eventuall will be mixed with other events)
  • date time
  • comments to the editors
  • comments to the viewers that eventually will see the video

• when you cannot record the presentation screen with a camera or a video mixing device,ask the speaker if he can record the session himself - we had that case, that Enrico said after the talk, he perfectly would have been able to make a screen movie of everything.if the speaker can't on his own, try to provide him with the tools ( we tried with some VNC stuff, like DebConf5VideoVNC, but couldn't complete the solution in time ) needed, one on a specialpresentation notenbook,two tell the speakers where they can get the software and install it on their machines, three, have a cd available before the talk, so they probably can try to install it shortly before (risk of damaging the system shortly before the talk)
• gromit (GRaphics Over Miscallaneous Things) seems to be nice to have a screen pointer: http://www.home.unix-ag.org/simon/gromit/
• If you want to include the slides on the video, you should check that the font used in the slides is large enough for the distribution format (for example 360 x 240, mpeg1). If the font is too small or the slides are otherwise too complex, they become unreadable when the video is compressed.
• see John's notes below for some missing roles and shifts in the volunteer plan( e.g. daytime shifts for video editors, while running talks )

from the recording and processing team:

• Don't rely on remote storage of raw footage that will need post-processing! Copying DV files takes time!
• Don't use hacks like piping dvgrab through netcat, unless you don't have any large local storage.
• Use 2.5 USB disks large enough for one day's worth of recording, and plug them into the editing workstations (again, avoid copying). Sneakernet can have quite impressive bandwidth!
• Get LARGE disks for the editing workstations, and store the archive there, if possible.
• If large disks for the workstations are not available, use remote RAID for the processed video (batch copying after the work is done; no waiting)
• Obscenenly high-res screens or dual displays are good for editing work!
• 3 GHz CPU and Gigs of RAM are good for editing!
• Each editor needs a good pair of headphones.
• The party crowd and the musicians must be chased out of the video room while the editors are working.

Thoughts from JohnLightsey:

• Don't overuse the network...
  • Capturing to local disk is more reliable. Some of the videos have glitches in them which appear to be caused by capturing over the network.
  • Downloading a 15GB dv file to an editing workstation over 100mb lan takes 20 minutes! It's a massive waste of time.
  • Large 2.5" drives would be preferable.

• Don't wait to begin editing.
  • It's tempting to wait several days before digging through the recorded videos. On the other hand, if you start editing immediately it just might be possible to have everything done before people leave.
  • Volunteers who want to help with editing will need time to become accustomed to the tools. Start early and their help will have a major impact.
• Filming/Mixing.
  • IRC was a reasonable solution for coordinating the front camera and booth, but simple walkie-talkie's would have been better.
  • It would have been helpful for the video mixer to compare the light levels from the various camera and suggest adjustments. (Herman's camera was wonderfully versatile in this respect.)
  • Better tripods... Mine was a POS, and Herman's had a sticky head.

• Editing.
  • 70GB of disk space is unacceptable for a video editing workstation. 300GB should be a minimum.
  • It's unfortunate that Sid was borked at the time of Debconf, but the Sarge/Sid chroot setup was inconvenient. We can work around this in the future by picking a known good date and locking the machines to it via snapshot.debian.net.
  • Passwords..... Let's get these nailed down ahead of time so that editing time isn't lost waiting on passwords. LDAP did not meet our needs at Debconf5.
  • Encoding to the published and storage video formats should be automated and done off of the editing machines. Most of my time was spent waiting on ffmpeg rather than editing. (It was impracticle to move the files back to the videoraid server because of the network issues, space issues, and sarge/sid chroot issues.)
  • The video mixer saved an enormous amount of time compared to manual mixing with Cinellera. If the same type of equipment isn't available at future venues it would be prudent to bring it there.
  • The videoraid idea could have worked properly if it was in the same room as the editing machines and was connected by gigabit lan. To store everything in its original format, we would need somewhere around 1.5TB of space. It would also be nice to have a dozen 500GB IDE disks to copy the videoraid at the end of Debconf. Anyone interested in editing should be able to take home a copy of the videoraid. At the end of Debconf5 there were plenty of volunteers to help finish the editing, but no drives available to give them a copy.

• Great job everyone... See you at Debconf6!

---