Welcome to future home of Freedomware Marketing. The Tux Project is going to be shifting gears a bit. This site is set to become a grass-e-roots website where we can all work together to openly collaborate on promoting the use of Freedomware in our local communities. Whether you are a business owner who uses or offers Freedomware solutions, or an individual enthusiast. You will find that this is the place for you to share your promotional ideas and work together collaboratively in order to make them a reality.
From HTML to Video
Formalize/start an effort to convert text and HTML howto's into sophisticated video demos. Flash is a candidate as a target technology for the demos because it allows branching and programming to be integrated with video clips. Java applets are another candidate. Context sensitive DVD's are another. There are others.
The idea is to take good howto's and make a demo vid out of them. With suitable licensing, others can add to the vids. Naturally, adding can mean adding special effects, cleaning up noise, adding animation, etc, but another way to add to previous works is to use flash/java/etc to build sensitivity into the videos at key moments in key locations. So whereas someone might make a vid on how to set up cinelerra starting from Live CD of Distro A ver. X already loaded, with access to the Internet, and 1 gig of memory to play with. Someone else might add a menu system to play, pause, rewind frame at a time, access menu, etc. Then someone makes sure that between frames 12345 and 12567 the menu selection will give the option to play a clip on troubleshooting some particular part of the howto shown during that scene where things might not work for the user (eg, maybe the person watching the video can't get their camara to work as shown on the video throughout the frames mentioned above). Someone else might prefix the original video with scenes of him/her installing Distro A ver X and getting up to the original initial point. Someone else might add a troubleshooting branch for resolving some issues during this new bootstrapping explanation. Someone else might add more menu items to allow for more types of or extensive troubleshooting. Someone else might add to the menus a way to jump to online docs that might explain something in a way the video did not cover. Someone else might add a menu entries that get activated throughout which branch off to context relevant reviews or to discussions on the hardware involved in the various portions of the vid. Another person might add icons that pop up during various scenes to indicate a new menu selection/branch point is in play (I think I've seen this on some DVD's). Someone else might add a workdesk to the video clip which the user can interact with to get the vid to respond in various ways (eg, move the pen over a sheet of paper to pop up a note pad; open a particular book or drawer to skip to a specific scene; draw a confused smiley face to log that this section of the vid was confusing; shift the monitor over to adjust the vid camara angle (this not realistic except for 3d animation vids); dim the light to adjust the brightness of the vid; click on an envelop to send a message/email to the author of the scene currently playing). ETC.
What I described got fairly sophisticated. In practice some software devs would work on an app to do most of these things, and the artist would have a simple way to hook their vids into it and program the branching and other components at a high level (eg, the clip authors/artists determine which app or plugin runs when the flash vid is prompted a particular way as precoded by the devs or by a plugin maker).
I would like to at least start making a basic demo video for works that I manage to put together and post online (text howto followed by demo vid). One of the first vids might be on how to make basic vids (screencasts, etc).
[*** Does anyone have suggestion for a digital camara that is a good value? It needs to work with Linux. I'd like for decent resolution and picture quality, but to save money, I'd skip on anything fancy that can be done relatively easy through software. I much prefer if FOSS drivers exist.]
Projects and websites that hold documentation and howto's might be open to the idea of converting their howto's into vids. Once someone gets the ball rolling, others should join.
I really think this will help the effort of spreading Linux. Variations on these sorts of ideas to make and take documentation, howto's, troubleshooting guides, etc, and turn them into something that is visual, aural, interactive, and context sensitive should help propel Linux distros/LiveCDs up one or more levels in terms of user friendliness. Also, when the basic processes are described and the steam starts flowing, many users out there might want to get involved, as the technically hard part might have already been done through the text howto's. What would most needed then would be photogenic (or not) individuals to give them life.
This idea is so hot!
I belive the biggest problem with this idea is that videos are much larger than programs, so I'm not sure where we can find a repository service for versioning such large files.
Also I belive we cannot use lossy compression during the creation of the movie, which creates another space constraint limit.
As far as I can tell, YouTube videos cannot be easily modified. -- am I wrong here?
There could be an option to store these video versions on our own computers (distributed repository), but that would generate a train load of other problems.
Got any ideas?
Video versioning brainstorming
>> I belive the biggest problem with this idea is that videos are much larger than programs, so I'm not sure where we can find a repository service for versioning such large files.
Traditional versioning tools are practical when diff is doable. If we can't diff in a practical fashion, we have to improvise versioning. The important part is to have the main video/sound segments. Every time someone modifies something, we just save all the cut up pieces, trying if possible not to duplicate. Anyway, even with a fair amount of duplication, people don't add video edits nearly as much as they might make text file edits (or we may institute a rule to control it).
Also, there are many websites that will host, and paying for web hosting is something many can afford (perhaps on others' behalf to share space). I anticipate that there will be cases of volunteering free web space to hold a certain amount of user contributions from others. This after we look at the places that already can be used to hold video or source (eg, sourceforge perhaps).
So, I'd agree that this is an important issue to keep in the forefront, at least until we find a good solution (like a utility to generate video segments from the contributions so as to minimize overlap (a video quasi-diff solution)).
>> Also I belive we cannot use lossy compression during the creation of the movie, which creates another space constraint limit.
We'll have to look at real numbers. I think it takes gigs to hold just minutes of medium to high resolution video. What would be our options for lossless compression (besides gz and bz2)?
One way to approach this is to let users figure out where they will hold their pieces and provide a link (distributed). Then we can aggregate into a central store low resolution/lossy versions. These versions can serve like story boards or something. Should anyone want to actually do something specific, they can reference the full vid and do what they need.
Each project may have to decide the prefered high resolution characteristics for that project.
We'll probably need to develop tools (eg, simple shell scripts to be run locally relying on cli tools, web interface to server processing, etc) so that users have an easy time getting what they need even when there is a mix of contributions (eg, a tool to extrapolate and change resolution to the preferred resolution; eg2, maybe a tool to automaticly capture/download only the desired full resolution clips after browsing the low resolution vids). Whatever, we can start easy. As the tools advance, it means less sophisticated users will be able to participate without help.
*****
I'm glad you noticed and pressed this particular trouble spot, btw. I'll try to keep my eyes open for examples on the Internet where people might have found ways around this.
I have a question. How are the graphics/vid files handled today in projects like 3d games? Perhaps only a very few contribute and they version publicly only/mostly finished works? I should drop by some of these projects and ask for suggestions.
*****
Ah, how about this. We might for example maintain one long vid segment that includes all unique contributions. Each distinct contribution (with a distinct and precise author, time, etc) would be documented based on which frames they apply to from the long segment. The low res and compact preview clips for each contribution might be created after processing this info on the backend (ahead of time.. but maybe real-time in some cases). The web interface would make it easy to know what existed.
So this long segment piece would effectively be the database (w/o duplication of anything if possible). The web interface (or other) would effectively become a sort of query language into this vid data store. Here we'd use the preferred resolution (as high as necessary). We might also store as related vids (usable by some of the "query" commands) that were in say higher resolution than the preferred resolution. The user would be able to learn the resolution available natively for the various clips.
Now how will we build all of this order from user contributions? And how will we verify the data if it is not uploaded (someone may have to upload and verify). [Initially, it'll probably be manual download/cut/paste/upload-to-datastore by a skilled volunteer, making sure to compute hashes.]
Also, what about that if distributed, it may disappear without others knowing. We can improve this situation by having the vids that are not spam or that are decent be identified and try to have 2 or 3 or X participating users download a backup copy (with checksum/hash). For this then, we'd just need a web interface to help coordinate the process from these volunteers (btw, you can volunteer and then store it in some free online site you have access to.. it doesn't have to be to a PC you control). We might want the users to give details of where they are backing up the vids so that we can identify potential troublespots (eg, maybe everyone uses the same public repo to backup, creating a single point of failure). In short, the more important material should be "mirrored" except that the mirror need not be a live link. We may for example have to provide an email request to the volunteer when we want to access a backup.
*****
Some details needed per project or globally:
-- Type of hash function/process (prob md5 and sha-1 of the specifically identified file).
-- database/db-interface
-- precise tools that will be used (eg, imagemagick; bash; libXXX; python/perl/php; javascript; etc)
-- resolution and format(s) (lossless)
-- resolution and format(s) (compact)
-- web interface (or other) to query, download/upload, and generally access/process clips.
*****
Some things we can do soon:
-- Inquire around town for solutions, advice, and general info/observations
-- Find some places to store the vids that others can partially rely on or use as a springboard
-- Do a mockup of the whole thing, perhaps picking a very simple project to video-ize.
Anyone have a special set of video demos they want done?
Anyone want to add to these very skimpy todo lists?
Any other gotchas or analysis of the above?
Any other suggestions, comments, etc?
[Note, this reply was edited several times minutes after initial posting.]
We might begin with these demos
I think focusing on key apps will also give a lot of mileage. One immediate benefit is that it will avoid distro wars for the most part because most of these screencasts+editing will involve having the application taking up all the vid screen; thus, different distro communities might be likely to participate by adding *new* tutorials instead of rehashing the same ones done already but in their flavor. What distro communities may want to do is to splice in the initial portion where we show how the application was started and/or configured in some way.
Another major advantage of attacking major apps early on is that they can be used by people working on Windows. I am thinking about OOO in this particular case. OOO and other office suites are important because they play a key role in breaking the Microsoft monopolies on the desktop, which is the largest roadblock to Linux adoption.
I would very much like to involve the communities of these major applications. Vids cannot only be standalone in a library of vids, they can be incorporated into the help system of the application. In fact, in this case, the effort might be to making small clips that could be use repeatedly. For example, accessing many features will involve first going through the same set of parent menus. There is no reason not to reuse a clip that shows this access once if done carefully. Perhaps they will want to standardize where to place the mouse on the way to opening submenus so that there is no choppiness in combining the menu access with any of the submenu accesses.
Another interesting set of vids for us might be showing how to accomplish various tasks on the Tux Project website.
Nothing I have said so far should be construed as an attempt to hold anyone back from making *any* sort of video because everything serves as inspiration for the rest. In particular, those involved with a particular community may very well prefer to work on demos that are relevant to their group.
Keep licensing in mind. Any vid intended to be cut up should use a license that allows others to do that. The author may want to dual/multi license for maximum flexibility, especially if any of the licenses are copyleft since any one of these would be incompatible with all/most other licenses, in particular with other copyleft licenses. Examples of such copyleft licenses that make good candidates for mutliple licensing are GPL, FDL, and CC Share Alike.
Besides screencasts and the occassional live filming, 3D and 2D animation can come in very handy. . .and don't forget narration!
Standards should be developed, but how to standardize may not be clear until at least several competing videos exist. We don't want to curtail creativity or people working in environments where they feel comfortable, but some standards may nevertheless be useful. Particular projects will almost surely want L&F and other standards. Standards should be for those that want them. It is important work but as important are techniques brought out in completely unstandard shots. [See http://thetuxproject.com/node/251#comment-725 ]
What might we title a TP project or a distro that exemplifies a video howto approach: ???
-- Simple Linux
-- Linuxeasy
-- Hold My Hand, Tux
-- Walk with Me, Tux
-- 1 2 3 Linux
-- Show Me Linux
-- Penguineasy
Maybe we will want to work on more focused subprojects with more focused titles that those just mentioned.
Screencast may be a good start.
If we could decide on a standard look for each of the DEs and use the same icon set window decorations etc... We could start this effort focusing on screen casts. We should work together to develop a list of common things people new to GNU/Linux would want to do.