[Video] Recording premix?

[Paul Wayper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/22/2013 09:32 PM, Carl Karsten wrote:
> 
> This is all an edge case, so low priority, but I do want to keep it on 
> the todo list.
> 
> Post editing does happen, but not for most/all of the time.  I have spent
> time bluring out a phone number, or removing 5 min of dead air when a
> preventer's laptop dies.  It sucks, but for the times when things are
> really broken, it is nice to be able to fix them.

I sympathise with Tim's point of view that it's much better to simply push
the entire video out once it's recorded than try to take it back and edit it
afterward.  I have several recorded CLUG talks that I haven't got around to
editing together and distributing.

But I think CLUG talks have completely different requirements from LCA
talks.  At LCA, you need to do that extra process of editing - partly
because you can't exactly rely on the original editor getting the start and
stop points right, partly because sometimes technology fails and you have to
fix things, and partly because sometimes we do need to remove a particular
comment or section from a talk due to various reasons.

> veyepar editing scales enough.

IMO veyepar's editing system is actually very scalable.  Six trained editors
could prepare a day's talks in an hour.  Each person can be on their own
machine, independent of eachother.  It would be wonderful if it was all in
some clean, neat piece of software that tied in with the veyepar backend and
seamlessly allowed editors to work even on the same video - but that's a
mammoth task.  For what it is, it does its job very well.

> What will help is to be able to move some of the post production work
> into talk time - if the "start cut" is good, one more click in the UI so
> instead of marking a time on paper and using that to click a veyepar UI.
> If the operator is confidant in the start/end cuts, encoding/uploading
> could begin as soon as the talk is over.   This is really the same data
> flow so would not reduce video production quality at all.

What I wanted to do at LCA 2013 was to have said team of editors.  At each
break we'd suck down the previous session's worth of talks and mark them up
them.  They could then be encoding while the next set of talks were being
recorded.  This would vastly speed up the process - we could literally walk
out of the AV room at 6PM and have all the videos from that day up by the
next morning.

That didn't happen, partly because the server died twice, partly because the
AV team was given a whole bunch of other problems to fix, and partly because
the things I expected to work failed dramatically (such as dvsink recording
off a remote dvswitch directly to the server created a new file every second
or two in practice, despite it recording correct, whole files in testing).
We were only able to get to actually editing talks on Saturday morning -
after we'd packed up everything and moved it to a new room - and Tomas and I
churned through a lot of the mark-up in that afternoon.

I definitely think that overlapping the recording of one session of talks
with the marking up of a second and the encoding of a third is going to
deliver much better gains in output speed and turnaround time than trying to
render immediately after the room operator has finished.

Hope this helps,

Paul
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlHGFYYACgkQu7W0U8VsXYJVVgCfSw5HHv1l+67j7M5BnivfGPYh
dMEAnjDeUA83C7QqRYPDOry9aKc2LdCD
=6CtQ
-----END PGP SIGNATURE-----