Since then I have had varying success capturing hours of video from both Hi8 and VHS sources. Often lavrec will exit in the middle of a recording with somewhat unknown error messages such as:

# dmesg:
DC10plus[0]: jpg_sync - timeout: codec isr=0x00

# lavrec:
Error syncing on a buffer: Timer expired

… and other nicies.

Often this happened between recordings on the tape, when stopping and starting a recording, where it often occur a lot of noise and jitter. It happened more often when recording from VHS tapes than from HI8 tapes.

I tried different values for the system configuration kernel.sched_time_avg with what looks like random improvements. The default is 1000 on a normal Ubuntu Desktop 10.10. I have tried both 100 and 250, and 250 is what I am currently using. Change it like this:

$ sudo sysctl kernel.sched_time_avg=250

I was previously using KDE while recording, but found out that several background processes like Akonadi Server was running and stealing resources. The window manager seemed slow. I guess I have an I/O issue somewhere, but I just don’t know where. Maybe the SCSI drive or maybe the graphics card which is an old ATI Radeon 8500.

I an now running Openbox with Konsole, as a command line (in an X server) is all I need to both record and watch the result with mplayer afterwards. I feel it goes a little bit smoother.

The most effect, as I figured out, was setting the quality option of lavrec a little lower. Recording with the quality set to 100 might result in unstable recording with lost frames if there is the slightest delay in the system, and eventually lavrec just exits with an error.

I tried setting the quality to 80, just to give it a try, and it was recording much more smoothly with less dropped frames. It looks like lavrec now handles jitter much better.

I am now trying out a quality of 90 which also seems good. A little lost frames now and then, but I guess that occurs mostly between recordings since I am able to record several minutes from a single scene without a single frame drop.

This is the command I use now:

$ aoss lavrec --mjpeg-buffers 512 --mjpeg-buffer-size 8192 -f q -d 1 -i p -q 90 -s -R l -U "dc10-%02d.mov"

So, my best tip to avoid lost frames and lavrec crashes is to lower the quality a little.

First, the camcorders charger is broken, and buying a new one is kind of difficult, but luckily, I got to borrow one from some friends.
Second, I managed to find the last working VHS player I got. A little dusty.
Third, since Mini-DV is kind of legacy as well, I decided to copy those on to my computer as well, if I ever manage to find the camcorder. Got the charger, remote and the casing, but no camcorder. Oh well…

Find the best composite or S-Video cables you can dig up, because this job you only want to do once. I got my overly priced Monster composite cables, ready to start. Soon…

Ok, so I’ve got an analog video capture card that I, in the old days, used with Windows 98 and pulled my hair out to get working on Windows 2000. The card is a Zoran based Pinnacle/Miro DC10+. That’s history. Sort of. I still got the video capture card.

What I also got is the latest Ubuntu Linux 10.10, also known as Ubuntu Maverick, which comes with the somewhat great ALSA audio support. I say somewhat because this version of Ubuntu lacks the legacy OSS compability driver in the Linux kernel. In other words it makes it harder to record or play audio from older kinds of programs, such as lavrec.

lavrec is the video and audio capture application from the MJPEG video tools package. It is the tool recommended for capturing video from the DC10+ card on Linux, but it lacks ALSA support. However, you can get a OSS wrapper program named aoss from the Ubuntu alsa-oss package which provides OSS is most cases for those old applications.

This is how I do video and audio recording, from the command line, enter something like this:

$ aoss lavrec -f a -i p -q 100 -s -R l -U dc10-out.avi

Make sure that the correct recording input line is selected for CAPTURE in alsamixer -V capture such as Line or Mic. I recommend you capture a 10 second test and check the sound.

Debian Lenny
Debian kom for en stund siden i ny stabil versjon, “Etch”, og siden jeg fortsetter å holde meg på testing-versjonen så var det på tide å oppgradere til neste versjon, som er “Lenny”. Det gikk litt sakte å navigere rundt i Freevo fordi maskinen har så lite minne, og oppstart av Enlightment som var installert på boksen gikk slimete tregt. Målet er å kunne bruke PC-en til noe nyttig igjen.

Videoredigering
Tidligere har jeg brukt en Athlon 1800+ til videoredigering, men redigering av HD-video tar mye ressurser, og jeg frykter at denne blir for treg. Jeg har en relativt kraftig maskin som stue-PC i leiligheten min som nå bare kjører MythTV. Denne har dual-core prosessor Athlon 5600+, og denne ønsker jeg å bruke til litt videoredigering. Det er derimot ikke optimalt å bruke TV-en som skjerm når jeg skal redigere. TV-en er bare “HD-ready” med en oppløsning på 1280×720, som blir noe snaut. Jeg har en 22″ widescreen LCD-skjerm som da egner seg bedre, men denne står i et annet rom og egner seg ikke for stua av opplagte grunner (ja, den tar jo litt plass). I tillegg frister det ikke så mye å koble om på kablene bak på stue-PC-en.

Dermed blir kanskje løsningen tynnklient-teknologi. En relativt dårlig PC (les: 733 MHz) kobler seg på X-serveren på en relativt kraftig PC (les: stue-PC), og signaler fra mus og tastatur blir sendt til X-serveren og skjermbildet blir sendt tilbake. For å få noe fornuftig opp på skjermen bruker man XDMCP, som støttes av innloggingstjenester som KDM, GDM og XDM. Jeg utførte en enkel test med å koble 733MHz-boksen opp mot laptopen, som vi fra nå av kaller henholdsvis tynnklient og tykklient.

XDMCP
Som sagt er XDMCP en protokoll for å koble på X-sesjoner, enten på lokal PC eller på andre PC-er i et nettverk. Det vi ønsker å oppnå er å koble oss på en innloggingstjeneste på tykklienten og få skjermbildet opp på tynnklienten. Til det skal vi bruke SSH med X-videresending, Xnest som er en X-sesjon som kan kjøres i et vindu i en annen X-sesjon og KDM som innloggingstjeneste.

Først måtte det gjøres noen konfigurasjonsendringer i KDM, som er den innloggingstjenesten jeg benytter på laptopen, som er en del av KDE-prosjektet. I konfigurasjonfilen /etc/kde3/kdm/kdmrc endret jeg på seksjonen Xdmcp for å aktivere tjenesten. Her vises et lite utdrag fra konfigurasjonfilen:

[Xdmcp]
Enable=true

Deretter måtte jeg endre i filen /etc/kde3/kdm/Xaccess for å fortelle kdm hvilke maskiner som får lov til å benygge innloggingstjenesten. Dette gjøres ganske enkelt ved å la kun ordet “localhost” stå skrevet i denne fila. For å tillate alle adresser på nettverket tilgang til tjenesten skriver du en stjerne, “*”. Grunnen til at jeg kun oppfører localhost kommer vi videre inn på snart.

Oppkobling
På tynnklienten startet jeg opp en enkel X-sesjon og terminalprogrammet xterm. Så logget jeg inn på tykklienten med ssh med kommandoen:

ssh -X tykklient

Opsjonen -X betyr videresending av X-applikasjoner som gjør at alle grafiske applikasjoner jeg starter i SSH-sesjonen blir vist i X-sesjonen til tynnklienten. Dette vil for mange være akkurat det de trenger dersom de har en egen window manager (som KDE eller Gnome) på PC-en sin.

Dette er ikke nok for meg. Jeg vil ha mer. Jeg skriver så inn følgende kommando:

Xnest :1 -geometry 1024×768 -query localhost

Opsjonen -geometry setter jeg til samme størrelse som min lokale X-sesjon. Dette kan du sjekke med kommandoen “xdpyinfo”, og se etter noen de første linjene som printes av dette programmet. Opsjonen -query henviser til tykklienten, fordi vi er inne i SSH-sesjonen på denne maskinen. Her ser du grunnen til hvorfor vi førte opp kun localhost i Xaccess-konfigurasjonsfilen over.

Dette oppsettet gir oss tre fordeler. For det første åpner vi ikke tjenesten for ukjente maskiner på nettverket, for den andre at alle tynnklientbrukere må ha gyldig konto på tykklienten for å logge på med SSH og for det tredje vil all trafikk bli kryptert over SSH-forbindelsen. I tillegg vil en brannmur kunne gi enda bedre sikring på punkt én.

Da var det bare å logge inn og fyre opp kdenlive, videoredigeringsprogrammet jeg bruker og har blitt så glad i. Avspilling av videokilder i kdenlive gikk bra, så da er 733MHz-boksen klar til å bli shippet over til leiligheten.

Påsken er over
Da er påsken over for i år. Jeg vet jeg lovet å undersøke mer omkring søkemotoren Solr, men det ble det ikke tid til. Jeg har så vidt touchet temaet søkemotorer og synes det er et spennende tema. Mulighetene er også tilstede for å ta i bruk Solr eller andre søkemotorer i kommende prosjekter på jobben i nær fremtid.

Jeg har brukt Windows primært for videoredigering, men siden det har blitt umulig å bruke Windows-installasjonen, så bestemte jeg meg for å teste ut den gamle Linux-installasjonen jeg hadde liggende på maskinen. Jeg putta så i SCSI-kabelen, endra boot-rekkefølgen i BIOS og boota Linux fra SCSI-disken min.

Det første som slo meg var at det var installert Gentoo Linux. Tror nok jeg bytter ut dette med KUbuntu etterhvert, da jeg har ymse erfaringer med oppgradering av Gentoo. Den bootet ihvertfall uten problemer.

Det neste jeg la merke til var kontroll av filsystemet:
/dev/sda3 has gone 1229 days without being checked
Artig, tenkte jeg da.

Litt synd at jeg ikke har brukt SCSI-disken min på så mange år, men kanskje det endrer seg nå. Ytelsen på SCSI-disken er det ihvertfall ingen ting å klage på:
# hdparm -tT /dev/sda
/dev/sda:
Timing cached reads: 1044 MB in 2.00 seconds = 521.04 MB/sec
Timing buffered disk reads: 204 MB in 3.01 seconds = 67.76 MB/sec
HDparm sin ytelsestest gir ikke det mest korrekte resultatet, men den gir ihvertfall en god pekepinn på hva man har i vente.

Da jeg fikk logget inn hadde jeg verken nettverkstilkobling eller lyd. Det var da jeg kom på at jeg hadde skiftet hovedkort i mellomtiden. Dette var derimot raskt å fikse. Nettverksgrensesnittet hadde bare byttet fra eth0 til eth2. Når det gjaldt lyden, måtte jeg inn og legge til via-driveren for ALSA-støtte i Linux-kjernen. Denne ble lagt til som modul, så jeg fikk søt musikk uten å måtte starte maskinen på nytt. Kjernen var av versjon Linux-2.6.7-gentoo-r11, installert 28. juli 2004.

VMware startet pent opp, riktignok etter en ny “vmware-config.pl”-runde. Denne Linux-installasjonen var så gammel at da jeg startet opp Mozilla, så fikk jeg beskjed om at Mozilla Suite var av gammel mote og at jeg burde oppgradere til Mozilla Firefox. OpenOffice var i versjon 1.1.2 og KDE i versjon 3.2.3.

aMSN fungerte også fint. Dette var en av de applikasjonen jeg fryktet at ikke skulle fungere, etter flere forsøk fra Microsoft i å stoppe bruk av andre klienter enn MSN Messenger. Nå husker jeg også hvorfor jeg har byttet til Gaim alle andre steder; nå har jeg 12 aMSN-vinduer oppe, hvor 10 av dem er uten samtaler, de har bare poppet opp på automagisk vis…

Nå har den kjørt i snart et døgn uten at maskinen har krasjet. Med det konkluderer jeg med at enten er min Windows-installasjon rett og slett ødelagt eller så har jeg noen dårlige IDE-disker stående i maskinen. Noen som har hørt om backup? Hmm…