# Raspberry Pi 4 o Pi 5 per replay 720p120

Ricerca del 16 ottobre 2026. Requisito: una camera, replay 5 secondi prima e 2 dopo il gol, controllo di porte/LED/ventola/display, Python come coordinatore; AI esterna, con eventuale tracking locale leggero. Non è stato eseguito un benchmark sul tavolo. Non è una selezione d’acquisto.

## Esito

**Pi 5 non è obbligatorio per registrare replay 720p120. Pi 4 è una candidata valida**, soprattutto con camera USB3 che emette già MJPEG e registrazione senza ricodifica, oppure con camera CSI e pipeline H.264 hardware ottimizzata. La conferma riguarda la configurazione reale sotto carico, non la capacità astratta di una periferica. Se si acquista un computer nuovo, Pi 5 offre più margine CPU per tracker, rete e interfaccia; non garantisce inferenza neurale a 120 fps né tutte le combinazioni di qualità/codec.

La scelta della camera e del formato può incidere più del passaggio Pi 4→Pi 5. Le camere e il loro crop sono confrontati in [ricerca-videocamere.md](ricerca-videocamere.md).

## Evidenza ufficiale e suoi limiti

[Raspberry Pi, camera software, Capture high framerate video](https://www.raspberrypi.com/documentation/computers/camera_software.html#capture-high-framerate-video) documenta come tentare 1280×720 a120fps con rpicam-vid, H.264 level4.2, denoise software disabilitato e senza anteprima. Riporta suggerimenti specifici Pi 4, incluso possibile overclock GPU: è una guida a raggiungere il target e ridurre perdite, **non una garanzia di120fps sul Pi 4 stock con tutti i servizi del tavolo**. Non adottare automaticamente overclock per dimensionare il progetto; misurare prima la pipeline nominale.

La stessa documentazione distingue Pi 5 con encoder software da Pi 4 con H.264 hardware. Pi 4 ha specifica nominale1080p30, che non è una garanzia di qualsiasi modalità a bitrate o risoluzione inferiore;720p120 è un target separato da verificare. Pi 5 può usare encoder software ottimizzati e preset diversi: non dedurre che sia incapace o peggiore solo dall’assenza dell’encoder hardware.

[White paper Raspberry Pi: H.264 encoding performance on Raspberry Pi 5-series computers, release1, aprile2026](https://pip-assets.raspberrypi.com/categories/685-app-notes-guides-whitepapers/documents/RP-010033-WP-1-H.264%20encoding%20performance%20on%20Raspberry%20Pi%205_series%20computers.pdf), letto integralmente nelle sezioni scope/metodo/risultati/conclusioni: confronta Pi 5 8GB Trixie e Pi 4 su sequenze1080p preesistenti, senza acquisizione né ISP. Le misure di codifica a30fps non costituiscono un test camera720p120+tracker. Conferma che Pi 5 software può offrire buona qualità e carico contenuto con i preset appropriati; non uso estrapolazioni di quel test per promettere il nostro frame rate.

Fonti hardware: [processori](https://www.raspberrypi.com/documentation/computers/processors.html), [hardware Raspberry Pi](https://www.raspberrypi.com/documentation/computers/raspberry-pi.html), [manuale Picamera2](https://datasheets.raspberrypi.com/camera/picamera2-manual.pdf).

## Tre pipeline da tenere distinte

| Pipeline | Pi 4 | Pi 5 | Punto critico |
|---|---|---|---|
| Camera USB3 MJPEG720p120 → buffer/file senza ricodifica | Candidata ragionevole; encoder Pi non coinvolto | Candidata con maggiore margine CPU | Frame UVC effettivi, timestamp, banda, buffer e storage |
| Camera CSI120 → ISP720p → H.264120 → buffer | Possibile target documentato, da ottimizzare e misurare; niente promessa stock | Codec software; misurare preset, qualità e carico | Intera pipeline, non solo fps del sensore |
| Registrazione120 + anteprima30 + tracking + rete + controlli | Registrazione disaccoppiata, tracking leggero/ridotto da provare | Preferibile acquistando nuovo per maggiore margine | Complessità del tracker, decodifica, code e temperatura |
| Rete neurale su ogni frame a120fps | Non garantita | Non garantita | Modello, input, acceleratore e benchmark dedicato |

Registrare MJPEG senza ricodifica evita l’encoder, non evita la decodifica se si vogliono analizzare le immagini. Il tracker può decodificare una selezione di fotogrammi; se servono120osservazioni/s per analisi dinamica, l’intera inferenza va misurata a120. Nel percorso CSI si può valutare un secondo stream a risoluzione ridotta per il tracker senza ricavarlo dal video compresso.

## Buffer, replay e controllo

Proposta iniziale: processo nativo di acquisizione e buffer di immagini compresse, Python per eventi e gestione; sensori gol restano l’autorità del punteggio. Conservare almeno5s prima del gol, poi2s dopo; a120fps sono840immagini. Riproduzione30fps:28s a velocità¼. Un replay può essere trasformato in un file30fps in differita; non serve mostrare120fps sul display.

Calcoli teorici, non benchmark:
- YUV420 non compresso720p120:1280×720×1,5×120 ≈165,9MB/s;7s≈1,16GB. Evitare questo come formato del buffer persistente iniziale.
- MJPEG se, **per ipotesi**, ogni JPEG medio fosse200kB:24MB/s e168MB per7s. Il valore reale dipende da scena/qualità, misurare media e picchi.
- Con H.264 il buffer è molto più piccolo, ma il taglio deve includere un keyframe valido e i parametri del codec; aumentare il prebuffer rispetto ai5s se serve. Non salvare una sequenza che comincia con un P-frame non decodificabile.

Un Pi 4 da4GB è una configurazione prudente per questo prototipo; aumentare la RAM non rende più veloce il sensore o l’encoder. SSD non obbligatorio per pochi replay compressi in RAM, ma utile per archivio; microSD/storage vanno verificati sul bitrate e sul carico reali. Sul Pi 4 camera USB e SSD USB condividono risorse I/O: misurare entrambi attivi. Raffreddamento e alimentazione adeguati in entrambi i modelli, soprattutto nel cassone chiuso.

## Criterio di accettazione proposto

Prima test camera10min senza preview, poi ripetizione con rete/preview/tracker e controlli. Verificare numero di frame, timestamp e intervalli reali, assenza di duplicati spacciati per120fps, salvataggio corretto dei7s, conservazione del FOV e nitidezza del disco. Registrare CPU, RAM, temperatura, eventuale throttling e carico I/O. Simulare molti eventi gol e correzioni mentre il buffer viene salvato; scollegare l’AI e controllare che il gioco continui. Un frame medio vicino a120 non basta se si perdono intere sequenze durante un gol.

Questa è una procedura proposta, non un test già eseguito. Scelta finale ancora aperta: riuso Pi 4 se disponibile; acquistoPi 5 se si vuole più elaborazione locale. Il requisito di un solo computer non elimina i driver RGB/ventola, ADC esterno per il potenziometro e nuovo bilancio di potenza.