Per celebrare l’uscita di Vista, prendete Word, create un nuovo documento e scrivete – o copiate e incollate – la seguente frase, estrapolata dalla tesi di Zangurt, laureando in Agraria:
Quest’area è circondata da campi di seminativi, ma a cento metri…
Bei prodotti, eh?
(Testato su Word XP/2002, spero che le versioni più recenti non ne soffrano…)
EDIT: Quello che succede è questo (Notare che ho installato Word apposta per fare questo screenshot):
Pare comunque che siano corsi ai ripari abbastanza presto, e basti fare un aggiornamento di Office per ovviare al problema.
gennaio 29th, 2007
Questa è geniale, e non posso non postarla! So che i colleghi ingegneri la apprezzeranno…
Egregio Signor giudice,
Ho visto perfettamente il segnale di limite di velocità: era bianco con bordo rosso e portava all’interno ben visibile la cifra 50, senza alcuna altra indicazione di unità di misura. Lei ben sa che il Regio decreto 23 agosto 1890, n. 7088 rende obbligatorio l’uso del Sistema Metrico Decimale in Italia, e che la Direttiva del Consiglio CEE del 18 ottobre 1971 71/1354/CEE modificata il 27 luglio 1976 (76/770/CEE), ratificata successivamente dal governo italiano, prevede l’obbligatorietà di applicazione di tale sistema SI. Orbene, per tale sistema metrico, le unità di misura da considerarsi sono, per la lunghezza, il metro, e per il tempo, il secondo. Di conseguenza, signor giudice, risulta evidente come la unità di velocità debba legalmente considerarsi il metro al secondo. Non oso neppure immaginare che il Ministero preposto non applichi le leggi della Repubblica. Pertanto, per quanto sopra esposto, 50 metri al secondo corrispondono esattamente a 180 Km/h. La Polizia afferma che la velocità della mia vettura – rilevata da apparecchiatura elettronica omologata – era di 177 Km/h, e questo non lo contesto. Semplicemente, faccio rilevare, viaggiavo a 3 Km/h al di sotto del limite autorizzato. Per quanto sopra esposto, chiedo pertanto l’annullamento della contravvenzione e la restituzione della patente. Distinti saluti.
(Thanks Rev)
gennaio 25th, 2007
Dato il mio ultimo acquisto, di recente ho dovuto forzatamente scontrarmi un po’ col mondo dell’encoding/editing video, andando oltre la semplice transcodifica di cui mi ero già occupato. La mia idea era quella di registrare in digitale gli episodi di Blue Heelers, un orrendo telefilm di poliziotti australiani, trasmesso in Italia dalle reti regionali a orari improponibili, e di cui sono probabilmente l’unico appassionato. Ovviamente, volevo fare il tutto con software libero.
Su come registrare da una scheda TV analogica con GNU/Linux c’è in giro abbastanza materiale. Purtroppo, però, pare che tutti tendano a encodare direttamente in MPEG-4, cosa che non mi piace per tutta una serie di motivi. Innanzitutto, dato che la codifica deve avvenire in tempo reale, non si possono usare i parametri avanzati per aumentare la qualità della compressione. Secondo, voglio poter eliminare la pubblicità e tagliare i bordi neri attorno all’immagine, senza contare che la mia antenna fa abbastanza schifo, e quindi vorrei anche poter passare il tutto in un filtro per l’eliminazione del rumore. Ultimo discorso è il deinterlacciamento, che nella pratica ho trovato essenziale. Non vi spiegherò cos’è, ma in giro troverete molti documenti in merito.
Al solito, chi è interessato legga l’articolo intero.
Premetto che quanto segue può non essere il modo migliore di fare le cose, dato che l’ho messo a punto io senza esperienza sul campo. Per questo, si accettano volentieri commenti e suggerimenti.
Scartando ovviamente l’ipotesi di comprimere al volo in MPEG-4, editare e ricomprimere, e quella di salvare i frame in formato non compresso per comprimere solo dopo l’editing, causa voracità di spazio su disco intrinseca della cosa, serve un formato intermedio che abbia le seguenti caratteristiche:
- Comprima, ma non troppo
- Comprima in realtime
- Non utilizzi frame che dipendono l’uno dall’altro, cosa che renderebbe difficile l’eliminazione della pubblicità
Inizialmente, la mia scelta è caduta sul formato DV, ossia quello utilizzato dalle telecamere digitali. Quanto al programma, come già detto, ho scelto mencoder. Per evitare di dover ricordare a memoria tutti gli switch che ho capito di dover utilizzare, ho sfruttato i profili che mette a disposizione. Ho creato un file .mplayer/mencoder.conf col seguente contenuto:
[rectv]
profile-desc="DV recording"
ovc=libdv=1
oac=copy=1
tv=driver=v4l2:width=720:height=576:norm=PAL:fps=25:chanlist=europe-west:amode=1:alsa=1:adevice=hw.1,0:audiorate=32000
Vediamo riga per riga:
- rectv: Nome del profilo, che va racchiuso tra parentesi quadre.
- profile-desc="DV recording": Descrizione arbitraria del profilo, che non ho ancora capito quando viene mostrata.
- ovc=libdv=1: Output Video Codec, dice a mencoder di utilizzare il formato DV per l’output.
- oac=copy=1: Output Audio Codec, abbastanza ovvio, fa sì che l’audio sia copiato pari pari come viene ricevuto (PCM) nel file di output.
- tv=...: Parametri per la ricezione della TV. Sono tutti abbastanza ovvi, tranne quelli sull’audio, che dipendono strettamente dalla scheda utilizzata. Nel mio caso, utilizzo il modulo del kernel saa7134_alsa, che crea un dispositivo audio (hw:1,0) dal quale mencoder può leggere l’audio ricevuto dalla scheda.
Ho poi scoperto che la codifica DV è terribilmente pesante, e l’unico modo che avevo per non perdere troppi frame sul mio “misero” Athlon64 3200+ era lanciare mencoder con una priorità piuttosto elevata. Il comando che utilizzavo quindi per registrare era il seguente:
sudo \\
nice -n -5 \\
mencoder -profile rectv tv://2 -o tv.avi
Mentre registravo in questo modo, l’utilizzo della CPU andava oltre il 90%, impedendo l’utilizzo del PC per fare altro contemporaneamente. Nel tentativo di migliorare la situazione, ho chiesto lumi in giro, e Giustino mi ha suggerito di utilizzare il formato Motion JPEG (MJPEG), in cui, in pratica, ogni fotogramma viene compresso come un’immagine JPEG, cosa che su una macchina moderna è relativamente veloce, data anche la risoluzione non elevatissima. Ho quindi creato un nuovo profilo:
[rectvm]
profile-desc="MJPEG recording"
ovc=lavc=1
lavcopts=vcodec=mjpeg:mbd=2:autoaspect=1:dia=2
oac=copy=1
tv=driver=v4l2:width=720:height=576:norm=PAL:fps=25:chanlist=europe-west:amode=1:alsa=1:adevice=hw.1,0:audiorate=32000
L’unica differenza rispetto al precedente è l’utilizzo del codec lavc, con alcune opzioni (lavcopts) che aumentano la qualità della codifica, su cui non mi soffermo (aggiungo però che trell manda il tutto in un simpatico Segmentation fault).
In questo modo possiamo registrare la TV analogica in un formato digitale mantenendo una certa qualità e senza nessun limite imposto al post-processing. A quale prezzo, però: un’ora di video codificato in MJPEG con audio PCM occupa circa 8,8 GB, mentre in DV circa una volta e mezza: 13 GB.
Nel prossimo articolo vedremo come effettuare il post-processing e convertire il tutto in MPEG-4.
gennaio 22nd, 2007
Bene, ho appena scoperto che forse i New order stanno per sciogliersi.
Questo significa che, per l’ennesima volta, mi sono appassionato di un gruppo appena prima della loro fine. Figo.
gennaio 12th, 2007
Per Natale, il mio PC mi ha regalato un nuovo periodo di stabilità, facendomi trovare una configurazione funzionante. È “bastato” rimettere il BIOS 27 (stavolta direttamente dalla schermata di boot, premendo ALT+F2) e solo uno dei nuovi blocchi di RAM, nello slot 1: in questo modo gli errori di lettura su disco sono scomparsi e tutto funziona come dovrebbe. Ne sto approfittando per backuppare tutto il necessario e per fare alcuni lavoretti urgenti, prima di tornare a smanettare.
Sempre per Natale, io ho regalato a me stesso una simpatica scheda TV. Si tratta di una Terratec Cinergy HT PCI, scelta abbastanza a caso, a dire la verità. Mi ispirava perché, per un prezzo abbastanza contenuto (79,90 €), supporta sia la TV analogica che quella digitale, oltre che la radio FM (anche se non ho ancora capito con quale antenna!) e la cattura da ingressi S-VHS e video composito. Ovviamente, a questo prezzo, non ha un encoder/decoder hardware, ma poco male: il mio Athlon64 e mplayer/mencoder (purtroppo il mio adorato ffmpeg non credo possa leggere dalla scheda) sopperiranno facilmente. In realtà, la compatibilità con Linux è un po’ sommaria: la TV analogica funziona benissimo con il modulo saa7134, con card=96 tuner=54, ma quella digitale dà un po’ di grattacapi. Sono riusciuto a farla funzionare, ma bestemmiando non poco. Per ora vi risparmio il procedimento, ma mi sono iscritto alla mailing list di LinuxTV.org per avere un contatto diretto con gli sviluppatori e cercare di risolvere il problema. Ho anche aperto una pagina sul loro wiki dedicata alla scheda.
Vi terrò informati…
gennaio 5th, 2007
