Free video software for linux

videocheck project is a simple program for checking and analyzing video AVI file structure.

The program is useful for recovering broken AVI files or finding bugs during development of software that produces AVI files.

video2wii is another service menu for KDE, this time to convert a video for nintendo wii.

It depends of the ffmpeg.

It looks like this:

[Desktop Action 2video4wii]
Exec=cd "%d";konsole --noclose -e ffmpeg -i %u -vcodec mjpeg -acodec pcm_u8 "`echo %u | perl -pe s/.[^.]+$//`.avi"
Icon=video
Name=Convert to video for Wii
Name[es]=Convertir en video para Wii

[Desktop Entry]
Actions=2video4wii
Icon=video
Name=2wii
Name[es]=2wii
ServiceTypes=video/*

Video server is a streaming video server which feeds a Java applet/application for display. The updates are rather slow, somewhere in the 10 frames/second range on a PIII. The server is written in Bigloo scheme and C. The client is written in Java.

To bring up the video server you have to do the following.

./vs --channel 25 --sd 12 --input 0

./vs --help
for more options. (This seems broken with the newest version of bigloo .... )

How to bring up a java client to connect to a server:
Insure that video/java is in your classpath, and invoke

java vpanel servername

video-entropyd is a program to add entropy data from video4linux devices to the kernel random driver.
For security reasons (when doing network traffic or generating secure keys for example) one wants as much entropy-data in the kernel random-driver as possible. The random-driver takes partially care for this. But in situations in where theres a lot of demand for entropy-data, it might not be able to gather enough entropy-data by itself.
Thats where this program is for: adding entropy-data to the kernel-driver. It does that by fetching 2 images from a video4linux-device (with a random delay in between), calculating the difference between those two and then calculating the number of information-bits in that data. After that, the data with the number-of-entropy-bits is submitted to the kernel-random-driver.
After that, the program exits (when run from crontab) or sleeps a random time before redoing the same process.
Enhancements:
- This version checks the quality of the data it feeds to the /dev/random-device to see if the data is really random.
- Extra logging has been added.

Ook? Video Ook! is a Firefox extension that enables you to download embedded videos.
Several systems are supported such as YouTube, Google Video, Pornotube, Metacafe and many more.
Main features:
- just one click downloading (just set a target folder on the options dialog once and then click on the status icon or the button where active).
- DownThemAll! integration for better download experience
- file renaming after video title (if you want so)
- files can be stored in a specific folder
- customizable toolbar button
- hideable status icon indicates which specific pages are supported: you can also check the About dialog to get a general idea
- send your requests for sites support or other comments directly from the extension (Im working on the server side right now)
- new support can be added on the fly using the autoupdate feature

WWW::Google::Video is a fetch the Google Video Information.

SYNOPSIS

use WWW::Google::Video;

$foo=new WWW::Google::Video;

$foo->fetch(http://video.google.com/videoplay?docid=1808273720725631796);
# The Google Video Page URL, such as http://video.google.com/videoplay?docid=blahblahblah

print $foo->{url},"n"; # Google Video FLV Original File URL !!
print $foo->{length},"n"; # Video Length Information
print $foo->{name},"n"; # Video Name Information

foreach(@{ $foo->{pic} }){ # By using Reference to an Array
print $_,"n"; # To show the preview pictures.
}

The WWW::Google::Video is a class implementing a interface for fetch the Google Video Information.

To use it, you should create WWW::Google::Video object and use its method fetch(), to fetch the information of Video.

It uses LWP::Simple for making request to Google.

Video::TeletextDB is Perl extension to manage a telextext database.

SYNOPSIS

use Video::TeletextDB;

$tele_db = Video::TeletextDB->new(%options);
# Possible options are:
# cache_dir => $directory
# mkpath => $boolean
# umask => $mask
# creat => $boolean
# RW => $boolean
# page_versions => $number
# channel => $string
# stale_period => $seconds
# expire_period => $seconds

$access = $tele_db->access(%options);
# Possible options are:
# umask => $mask
# creat => $boolean
# RW => $boolean
# page_versions => $number
# channel => $string
# stale_period => $seconds
# expire_period => $seconds

$cache_dir = $tele_db->cache_dir;
$channel = $tele_db->channel;
$old_channel = $tele_db->channel($new_channel);
@channels = $tele_db->channels;
$nr_channels = $tele_db->channels;
$boolean = $tele_db->has_channel(?$channel?);
$db_file = $tele_db->db_file;
$lock_file = $tele_db->lock_file;
$tele_db->lock;
$page_versions= $tele_db->page_versions;
$umask = $tele_db->umask;
$old_umask = $tele_db->umask($new_umask);
$RW = $tele_db->RW;
$old_RW = $tele_db->RW($new_RW);
$stale_period = $tele_db->stale_period;
$old_stale_period = $tele_db->stale_period($new_stale_period);
$expire_period = $tele_db->expire_period;
$old_expire_period = $tele_db->expire_period($new_expire_period);
$user_data = $tele_db->user_data;
$old_user_data= $tele_db->user_data($new_user_data);

$tele_db->delete(%options);

The idea behind a teletext database is to separate the process of collecting teletext pages from the process of presentation. This makes programs both shorter (you dont have to implement the side yourre not interested in) and more flexible (you can read teletext pages long after the collector stopped running and you dont have to be tuned in to the channel you want to read).

In fact, the simple script TeleCollect coming with this package will be good enough for most teletext collection purposes, so that you can concentrate on the page processing.

This modules provides you with methods to both store and retrieve pages into a database and some rudimentary support to manage a set of databases (typically one for each channel). The pages will be stored in raw form so that a client can decide for itself how to handle things like transmission errors (there are of suggested methods provided in the module though, so you dont have to reinvent the wheel every time).

It (currently) use a Berkeley DB with an external lockfile for the actual storage. It only uses the version 1.85 features, so it should work almost everywhere. There will be one database and lockfile for each channel and all channel databases and locks will normally be collected in one directory.