[Video] Power of documentation verse Software "which does the right thing"

[Carl Karsten]

DVSwitch is like a DSL (domain specific language) or video software
framework or .. library of components that you use to build the video
recording app that you need depending on your needs.

I have seen 3 or so approaches to building something for the end
users.  All have their pros n cons, none seemed to have been the
obvious good choice.    these approaches are basically some sort of
shell command management "hey user, do this simple thing to launch
some commands that have some configs that have been setup for this
event"

For this event <---

Which means someone has to figure out what the details of the event
are, like are where do you want to save the DV files to?   local hard
disk or central file server using NFS or a bunch of dvsink-file
commands running on a central server.

Figuring out these details is hard.  or something.  What would make it
easy is to remove all the choices.  example: you use 2 local DV feeds,
audio goes into the first one, you save to the local disk under
/dv/date/time.dv  - so no remote machine with a twinpact hooked up and
dv sent over lan.  remove that choice and things get easier.  except
you have to run the VGA cable to where the camera is.  But the
software is easier.

Tim's potable box takes this approach, which for the problem of
recording small events is good.  make it harder and it gets too hard
and nothing happens.


Documentation:
I have written tons of docs, I thought it was a good idea when I was
writing them, but over the 5+ years of doing this, I am sure I spent
more time on docs that if I had just tutored the people who needed to
know, and the one on one discussion would be way better use of
everyone's time.   There isn't a large enough user base to get the
benefits of lots of people reading the same docs.  This may change,
but I don't think the small head count is caused by a lack of docs.

And yes, practice practice practice. Live events impose some
challenges that armatures are not ready for.  When it is show time,
you don't have time to just bla bla bla... You need to A) have the
normal process down and B) when un-normal happens, you need to know
what to compromise on.



On Mon, Jun 17, 2013 at 5:56 PM, Tim Ansell <mithro at mithis.com> wrote:
> So, as shown below, Paul brought up the idea of documentation for the
> current system and I'd like to get other people's thoughts.
>
> What do other people think of the DVSwitch documentation? I think it's
> pretty good compared to many projects and there is quite a few "here is how
> I did it" stories out on the net.
>
> I feel that doing video capture can only really be learned by doing, even
> the best documentation can instill how important having things like spare
> power plugs available until you've found that you need it.
>
> The other thing I'd like to bring up is that very few people actually read
> the documentation and it's much better for the software to "just do the
> right thing". This is something I've been trying to do with the portable
> system. It automatically selects the right settings unless it needs a human
> to do something, then it displays a helpful page with pictures and
> explanation on what to do. More importantly, it won't let the person move
> forward until they have successfully fix the issue that is being reported.
> IE Actually plug in the power. Obviously this is limited to simple cases, I
> doubt we'll ever be at that point with conference recording - but just food
> for thought.
>
> - Tim
>
>>
>> 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.
>>
>> More or less.  My experience was that there were a few people who knew
>> about this system, but it wasn't well documented online.  The documentation,
>> such as the DVswitch page linked above, is terse, non-adaptive and mainly
>> handles the working case.  Unfortunately, I wasn't able to speak with the
>> people who really know this system - Ryan and Carl - and some of the other
>> people who do know it - Tristan, James Iseppi, Matt Franklin, Euan, Liam and
>> others - were only able to help educate me to a limited extent.
>>
>> The thing I think is really important in any system we come up with is
>> that it's well documented.  I know that's painful, I know that's boring, and
>> I know it takes a lot of time.  But it's essential to being able to help
>> other conferences and groups.
>
>
>
> _______________________________________________
> Video mailing list
> Video at lists.linux.org.au
> http://lists.linux.org.au/listinfo/video
>



-- 
Carl K