[Linux-aus] Council Meeting Minutes - 2011-02-03

[Ryan Verner]

On 04/02/2011, at 15:22 , Russell Stuart wrote:
> Beware that wasn't a deliberate choice by the LCA 2011 team.  It
> happened that way because parts of the video processing were done by
> outside volunteers to which we are both deeply indebted and
> appreciative.  They supplied the software.  If that software isn't
> changed, I suspect all the demands in the world to upload the videos to
> LA's mirror first aren't going to make it happen.

https://github.com/CarlFK/veyepar

Patches welcome.

I have to admit I'm a bit miffed by how huge this issue has become.  The reason why video was uploaded to blip.tv first is fairly simple, and it is not one of a deliberate decision to not use the LA mirror; we implemented an existing workflow stack that already uploaded to blip.tv and had absolutely zero time to refine this - please remember that the venue completely changed a week before the conference, this caused delays to the LCA network, the AV infrastructure was very dependent on this, and some very critical issues with the AV loop were discovered immediately before the conference.  We spent a *lot* of 2AM nights trying to debug everything so video recording would actually work.  Changing a working delivery method was way down on the priority list.

No, uploading videos to the LA mirror isn't a simple rsync of a directory unfortunately - encoded files can be in various states (clustered encode boxes writing to the same NFS share, QA processes, video delivery announcement processes, etc) so additional code would need to be written to handle this to control/track each video upload.  This won't be difficult to code, but it requires time we didn't have.

We made the decision to just deliver video in a way we knew worked to get things out as rapidly as possible, as we thought the community would appreciate this over delaying videos.  We uploaded both Flash and OGV.

Nobody *ever* said videos wouldn't be uploaded to the LA mirror - I'm sure they will be, once encodes are finalised and any videos with issues are fixed and reencoded.  Our use of blip.tv wasn't ever designed to be a mass consumption mechanism to suck down every single video for offline viewing.

The suggestion Jeff makes of building proper video delivery infrastructure to live on mirror.linux is a great one, and please make that happen - I would genuinely love to be involved - there are other communities I do video recording for that would benefit from a solution like this.  There are a multitude of reasons why delivering videos purely as flat files sucks, but I'll respond to that once I have more energy to do so.

I have my own personal issues with blip.tv - but it was a mechanism that worked previously, was utilised at OSDC with no complaints, and it allowed us to get videos out there quickly, so it seemed the right decision.

R