The DVR hardware in the setup ouputs four avi files–one for each camera. The first file has the audio encoded in it. Having four files is cumbersome, though. It’s much better to see the camera focused on the users face at the same time as video focused on the users hands, and at the same time as the view that shows the users screen.

That’s where gstreamer comes in. It’s possible to write a pipeline that can take the 4 videos and compose them together into one 4-way split screen.

In Mo’s post she showed an earlier pipeline I came up with, but it was very slow and lacked audio.

I’ve been reading up on gstreamer, searching the internets for example pipelines, etc, and now have a better pipeline. Someone here at the summit asked for me to check it into git, so I did that today in the usability-lab module.

• Showing the fingerprint in the dialog is only useful if the fingerprint is somewhere else the user knows to look
• You obviously can’t put where to look in the key itself, because the key isn’t trusted until the fingerprint is verified
• Since you can’t put it in the  key, discoverability is a hard problem.  We pretty much have to hope that the key is in plain view on the website that offers the package / repo.
• “trust” is a bit of a stretch in any case, because often users will google around for software and install whatever they find. It’s really more “verify the software comes from the website that originally pointed to the package / repo file.”
• Only users who really understand the security implications of the dialog are going to verify that the key fingerprints  match
• Given that most people who see the dialog aren’t going to verify that the key fingerprints match, the dialog isn’t useful for security (it only solves the identification problem for a small subset of users)
•  One way to make the dialog more secure would be to treat the fingerprint like a CD key / activation number that the user has to enter instead of something that gets shown to the user.   If entering the key was a required step for configuring a system to use a repository, then websites that offer repositories would have to include the fingerprint with the repo in plain view for the repo to be useful, and users couldn’t just click past the dialog without reading it.
• Some might argue that users are accustomed to entering these types of numbers already when installing software.  There’s precedent anyway.
• Having to enter long strings of numbers sucks (just as much as having to read long strings of numbers sucks)
• Either way, there’s a very real aesthetic problem with this type of dialog, and it’s not clear there’s an easy way to fix that
• One thing that can help is have the distribution know about a select number of 3rd party repos/keys out of the box, so then the dialog can hide the key fingerprint entirely.
• Figuring out which keys to ship within a distribution is an interesting problem itself, but maybe it should have some parallels to the processes that the distribution uses for adding packages?