[Video] Current state of the art for conference recording

[Euan de Kock]

Good point Carl. I think audio is an important aspect that needs to be 
considered.

There's a lot of different ways we are capturing audio, some of which 
work well, and some that doesn't, and some which impose a high task load 
on the volunteers manning the kit.

We're hoping to rationalize some of this leading into LCA2014, and we'll 
feed this back as we work through it.

Regards,

Euan de Kock,

President - Perth Linux User Group (PLUG)
Organising Committee - LCA2014 - Perth WA.

On 06/17/2013 09:50 PM, Carl Karsten wrote:
> On Mon, Jun 17, 2013 at 2:50 AM, Tim Ansell <mithro at mithis.com> wrote:
>> Hey guys,
>>
>> So I thought I'd quickly document what the current state is;
>>
>> TwinPac for VGA capture to DV,
>>
>> Firewire based camera for presenter using DV,
>>
>> Going into DVSwitch (pretty much as described by
>> http://dvswitch.alioth.debian.org/wiki/large_meeting/)
>>
>> veypar is used for conferences to allow quick processing of the large amount
>> of video, splitting into talks and uploading to YouTube/pyvideo/other.
>>
>> Going into Flumotion or Icecast for Live Streaming (least tested)
>>
>>
>> The current setup has been well tested and I believe well understood.
>>
>> However, the current setup has some limitations;
>>
>> Currently only SD resolution
>>
>> Getting features into DVSwitch is painful
>>
>> TwinPac is End-Of-Life and impossible to purchase new anymore
>>
>> Laptop's no longer have Firewire ports so ExpressCards must be used and have
>> a tendency to pop-out
>>
>> Firewire Cameras are becoming impossible to find
>>
>> Poor ability to integrate with other online systems such as HangOuts, etc
>>
>> Requires significant expert knowledge to run smoothly
>>
>> Requires 2 people per room.
>>
>>
>> Have I missed anything? What do you guys think?
>>
> Audio - which maybe is out of scope, but I think it should be mentioned.
>
> Requires 2 people - I think that should be better defined.    1 person
> can do it all, so I would not say "requires."
> "recommended" maybe?   I think what is a requirement is having a 2nd
> person for redundancy to being fault tolerant, and that will be the
> case regardless of what the people are doing.
>
> And then once I have the 2 people in a room, I load them both up with
> work, and I keep finding more things for them to do.  I need to make
> sure I don't over commit so if one person drops the remaining person
> won't be able to handle everything.
>