In questo appunto, riporto ciò che ho capito sulla registrazione video, con OpenBSD. Non sono un esperto dell’argomento, quindi la mia è una ricerca sicuramente incompleta, parziale, migliorabile, e come sempre mi capita di dire prodotta essenzialmente per me, e resa pubblica con l’aspettativa di avere qualche feedback.
Perchè tratto l’argomento? Perchè mi son sempre chiesto come certi utenti UNIX riuscissero a produrre i video tutorial , mi piacciono molto ad esempio quelli di esadecimale su Youtube. Vorrei riuscire a produrre un video di quel tipo, con un sistema minimale e con strumenti utilizzabili a linea di comando, e senza post-produzione, se non quella essenziale. In generale, ogni volta che tratto un nuovo argomento, mi capita quasi sempre di imparare cose nuove di UNIX e del mio Sistema Operativo preferito.
Da dove iniziare? Il punto di inizio è quello di procurarsi ad esempio una webcam, e capire se questo è supportato dal sistema operativo.
Dispositivo Video.
In questo periodo, ho finalmente un laptop decente tutto mio su cui ho installato OpenBSD 7.8 (da aggiornare alla 7.9). Si tratta di un Lenovo ThinkPad (Intel i5 con 16Gb di RAM), ed a qualcuno potrebbe scoppiare una bella risata ^___^ Non necessito di tantissima RAM al momento, ne di potenza elaborativa, ed OpenBSD supporta tutti i device inclusi in questa macchina, magnificamente. Anzi, a chi volesse provare questo magnifico SO, consiglio proprio di recuperare una di queste macchine.
Tornando a noi, per verificare se il sistema operativo è riuscito ad identificare la webcam, montata su questo modello di laptop, è necessario leggere i messaggi del kernel nella fase di boot, e cercare qualcosa tipo “video”.
Sappiamo che individua il dispositivo “SunplusIT Inc Integrated Camera“, e che associa ad esso il driver uvideo.
arcadia$ dmesg | grep video
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD1F
uvideo0 at uhub0 port 8 configuration 1 interface 0 "SunplusIT Inc Integrated Camera" rev 2.00/0.10 addr 3
video0 at uvideo0
OpenBSD cura ossessivamente la documentazione, che è uno dei pilastri del progetto. Un’errore nella documentazione è considerato al pari di un bug riscontrato nel codice. Chi usa questo sistema operativo può anche non avere la connessione ad internet, per ogni cosa ci sono e ci saranno sempre le man page, ed infatti anche il driver uvideo ha una sua documentazione specifica, così come tutto il resto. Se invece, avete la connessione ad internet e non un’installazione di OpenBSD a portata di mano, potete sempre leggere le man page alla seguente https://man.openbsd.org/OpenBSD-7.7/uvideo.4.
UVIDEO(4) Device Drivers Manual UVIDEO(4)
NAME
uvideo - USB video devices
SYNOPSIS
uvideo* at uhub?
video* at uvideo?
DESCRIPTION
The uvideo driver supports a range of USB Video Class (UVC) devices
including webcams, camcorders and other cameras. UVC is a generic
specification and many USB video devices follow it. The following models
are known to work:
o Apple built-in iSight
o Chen-Source CM12402 Eagle IR Cam
o Chicony Electronics 4807 (Lenovo X300 647815G Notebooks)
o Dynex 1.3MP Webcam
o Elgato Facecam Pro
o eMPIA Technology 2761 (ASUS EeePC 701 Notebooks)
o Jabra PanaCast 20
o Lenovo EasyCamera (Lenovo IdeaPad s10e Notebooks)
o Logitech QuickCam for Notebooks Pro
o Logitech QuickCam Communicate Deluxe
o Logitech QuickCam Communicate MP
o Logitech QuickCam Deluxe for Notebooks
o Logitech QuickCam E 3500 Plus
o Logitech QuickCam Fusion
o Logitech QuickCam OEM (Dell Notebooks)
o Logitech QuickCam Orbit AF
o Logitech QuickCam Orbit MP
o Logitech QuickCam Pro for Notebooks
o Logitech QuickCam Pro 5000
o Logitech QuickCam Pro 9000
o Logitech QuickCam Sphere AF
o Logitech QuickCam Sphere MP
o Logitech QuickCam Ultra Vision
o Logitech Webcam C200
o Logitech Webcam C310
o Logitech Webcam C500
o Logitech Webcam C920 Pro
o Logitech Webcam C922 Pro
o Logitech Webcam C930e
o Logitech Webcam Pro 9000
o Microsoft LifeCam NX-6000
o Microsoft LifeCam VX-500
o Microsoft LifeCam VX-700
o OmniVision OV7670 (Dell XPS M1330 Notebooks)
o Panasonic NV-GS320 Camcorder
o Rocketfish 2MP AF Webcam
o Sonix USB 2.0 Camera
o SunplusIT Inc (Lenovo X1 Carbon 6th Generation Notebooks)
o SuYin Acer Crystal Eye (Acer AspireOne Notebooks)
o Vimicro Corp USB 2.0 Camera
If the uvideo device attaches successfully, it will attach the video(4)
driver to provide higher-level access.
FILES
The driver needs a set of firmware for some devices which are loaded when
a device gets attached:
/etc/firmware/uvideo_isight_05ac-8300
/etc/firmware/uvideo_r5u87x_05ca-1803
/etc/firmware/uvideo_r5u87x_05ca-1810
/etc/firmware/uvideo_r5u87x_05ca-1812
/etc/firmware/uvideo_r5u87x_05ca-1835
/etc/firmware/uvideo_r5u87x_05ca-1836
/etc/firmware/uvideo_r5u87x_05ca-1837
/etc/firmware/uvideo_r5u87x_05ca-1839
/etc/firmware/uvideo_r5u87x_05ca-183a
/etc/firmware/uvideo_r5u87x_05ca-183b
/etc/firmware/uvideo_r5u87x_05ca-183e
/etc/firmware/uvideo_r5u87x_05ca-1841
A prepackaged version of the firmware can be installed using
fw_update(8).
SEE ALSO
intro(4), usb(4), video(4)
HISTORY
The uvideo driver first appeared in OpenBSD 4.4.
OpenBSD 7.8 August 14, 2025 UVIDEO(4)
Adesso che so che la webcam del mio Thinkpad è supportata, posso passare oltre.
Abilitare la registrazione video.
Di default nessun utente OpenBSD (incluso l’amministratore della macchina), è abilitato ad effettuare registrazioni di stream video provenienti da cam, o altro dispositivo; a salvaguardare la privacy dell’utente.
arcadia$ sysctl kern.video.record
kern.video.record=0
In caso di necessità, si può sbloccare la registrazione, anche solo temporaneamente, andando ad impostare ad True (1) il parametro del kernel kern.video.record, tramite il solito comando sysctl.
arcadia$ doas sysctl kern.video.record=1
kern.video.record: 0 -> 1
arcadia$ sysctl kern.video.record
kern.video.record=1
Al successivo reboot della macchina, tornerà il default. Per rendere permanente la modifica (sconsigliato) va inserita direttamente in /etc/sysctl.conf.
Permessi di R/W al file di device (/dev/video0).
Su UNIX, tutto è riconducibile per l’utente ad un file. Pertanto, anche la comunicazione tra l’utente (o un’applicazione utente in user space) ed un dispositivo hardware avviene normalmente tramite un’astrazione generata dal kernel, che l’utente percepisce come file di tipo speciale, posizionato sul filesystem. Ogni file presente nella directory /dev può rappresentare un dispositivo reale, ed in tal caso: scrivere in questo file speciale (che chiamerò file di device) equivare a voler inviare qualcosa al dispositivo hardware, mentre leggere da questo file equivale a recepire qualcosa dal dispositivo hardware. Ciò che permette questa astrazione, che noi utenti vediamo come fosse un comunissimo file, vi è il sistema operativo, o meglio il driver di dispositivo, un software che fa da intermediario tra l’applicazione utente ed il dispositivo hardware. Per un sistema operativo, supportare un hardware significa avere un tramite (driver) come comunicare con esso, il quale conosce il suo protocollo. Nel caso, ad esempio della mia webcam, come abbiamo visto il driver è uvideo e l’astrazione, ossia il file di device a cui esso si aggancia e controlla è /dev/video0 o /dev/video1. La cam invierà lo stream video ad uvideo e questo lo renderà fruibile all’utente tramite il corrispondente file di device, e questo permetterà alla nostra applicazione preferità di mostrarcelo in tempo reale, o registrarne il flusso in un formato mp4 (o altro). Chiaramente dobbiamo verificare di avere i permessi di R/W alla /dev/video0|1.
Con OpenBSD, di default, è esclusivamente l’amministratore della macchina ad avere i diritti di accesso in lettura e scrittura alla /dev/video.
arcadia$ # ls -ltr /dev/video0
crw------- 1 root wheel 44, 0 Dec 7 2045 /dev/video0
Quindi io non sarei autorizzato ad utilizzare la webcam, ed è giusto così, del resto non stiamo utilizzando una qualsiasi distribuzione generalista GNU/Linux, per utenti pigri.
Appartengo però al gruppo wheel, che su OpenBSD corrisponde ad essere uno degli utenti di cui l’amministratore della macchina si fida, la cerchia di quegli utenti che lo aiutano e che cui demanda per alcune cose. Naturalmente su un laptop personale, tutte ‘ste pippe a che servono, si stara chiedendo qualcuno, ed invece anche su un laptop ad utente unico tutto questo ha un senso. Utilizzare un utente con i privilegi minimo e non “root” è sempre una salvaguardia, ad esempio con la mia utenza nominale, anche solo per errore non mi sarà mai permesso di eliminare l’intero filesystem e essere veicolo di codice malevolo da internet.
id
uid=1000(jack0e) gid=1000(jack0e) groups=1000(jack0e), 0(wheel)
cat /etc/passwd | grep jack0e
jack0e:*:1000:1000:jack0e:/home/jack0e:/bin/ksh
cat /etc/group | grep jack0e
wheel:*:0:root,jack0e
jack0e:*:1000:
Il gruppo proprietario di /dev/video è wheel, ma di default non ha alcun permesso di R/W su di esso. Se io provassi a leggere o scrivere in questo file, otterrei un errore per mancanza dei permessi per farlo.
# TEST-1: lettura (tentativo di lettura dalla webcam)
arcadia$ cat /dev/video0
cat: dev/video0: Permission denied
# TEST-2: scrittura (invio di un "ciao" al dispositivo webcam)
arcadia$ echo "ciao" >> /dev/video0
ksh: cannot create /dev/video0: Permission denied
Per risolvere, posso dare i permessi di R/W al file di device /dev/video0 al gruppo wheel. Son sicuro che il file di dispositivo sia questo, e non magari /dev/video1|2|3|4|5 perchè so di avere un’unica webcam. Se ne avessi avete 2 o 3, mi sare posto il problema di capire quale webcam occupasse la posizione 0 e quale la posizione 1, 2 o 3, e così via.
arcadia$ chmod 660 /dev/video0
arcadia$ ls -ltr /dev/video0
crw-rw---- 1 root wheel 44, 0 Dec 7 2045 /dev/video0
Adesso, se ripeto il comando “cat /dev/video0” mi si accende il led verde della webcam ed ottengo una quantità abnorme di caratteri criptici come risposta nel terminale. Quello che vedo è lo stream che arriva dalla webcam. Per essere corettamente interpretato ho necessità di un riproduttore video. Intanto, interrompo lo streaming con un Control^C, che mi spegne nuovamente il led della webcam.
arcadia$ cat /dev/video0 > stream.txt
^C
arcadia$ hexdump stream.txt
Quello che si vede nell’immagine (a destra), è un dump in esadecimale di ciò che è arrivato dalla webcam. Le ultime 4 righe sono il tentativo (3 volte fallito :P, dii effettuare uno screenshot della videata)
Verifica di funzionamento della webcam.
Se tutti i passaggi precedenti hanno dato esito positivo, possiamo provare ad utilizzare in maniera normale la nostra webcam. Per farlo dobbiamo munirci di un’applicazione di un player multimediale. Nel caso di OpenBSD, non è presente nell’installazione base, quindi è necessario ricercare quella che piu’ ci aggrada, consultando ad esempio forum specializzato ed altre fonti, ed installarla. Nel mio caso avevo già installato l’ottima ffmpeg, quando ho trattato quando mi sono cimentato con l’audio. Ricordo che con OpenBSD per installare un pacchetto è necessario eseguire come amministratore (o farsi abilitare a farlo) il seguente comando
arcadia$ doas pkg_add ffmpeg
Per avviare la webcam, è necessario utilizzare di ffmpeg il comando ffplay, fornendo il file di device associato alla webcam (-i /dev/video0) e forzare ffplay ad utilizzare X, impostando come formato video (-vf) yuv420p. Ho specificato questo, perchè con il formato di default non riuscivo ad eseguire lo screenshot dello schermo con il comando.
arcadia$ ffplay -vf format=yuv420p -i /dev/video0
Registrazione di uno stream da webcam come mp4.
Se volessi registrare lo stream video in un file (ad esempio mp4), anzichè vederlo in tempo reale, dovrei utilizzare direttamente ffmpeg, e non ffplay che rimane un player minimale, primo di tante funzioni. Per farlo potrei eseguire il comando :
arcadia$ ffmpeg -i /dev/video0 Download/openbsd-video-recording.mp4
^C
…ed usa CONTROL+C per interromperlo, magari con qualche secondo di ritardo per permettere ad ffmpeg di svuotare il suo buffer. Quello di seguito è il video prodotto.
Conclusioni
Questa è *solamente* una prima esplorazione sull’argomento. Ho ancora tante curiosità nello stack, quindi l’esplorazione continua…