Posso registrare un video di 24 ore su Raspberry Pi con il modulo videocamera?


12

Dato che ho una scheda SD con capacità sufficiente, è teoricamente possibile registrare un video di 24 ore con un modulo videocamera o la durata della registrazione è limitata? Qualcuno ha provato questo?

Pensi che 64 GB siano sufficienti con una qualità di registrazione a 360p?

Risposte:


20

Devo ammettere che non ero a conoscenza della limitazione di 2Gb nella build stock di raspivid (menzionata nella risposta di Linus). Un'alternativa (se non ti va di ricompilare la userland) sarebbe quella di usare Picamera (Python supporta puntatori di file a 64 bit pronti all'uso ). Ad esempio, quanto segue dovrebbe registrare un video a 360p widescreen in H.264 felicemente per 24 ore:

import picamera

with picamera.PiCamera() as camera:
    camera.resolution = (640, 360)
    camera.framerate = 24
    camera.start_recording('one_day.h264')
    camera.wait_recording(24 * 60 * 60)
    camera.stop_recording()

La parte successiva della domanda è se si adatta a una scheda SD da 64 GB. Il mio sospetto è "probabilmente", ma verificiamo che ...

bitrateAll'encoder H.264 del Pi può essere assegnato un limite di bitrate con il parametro nel metodo start_recording di picamera o il --bitrateparametro in raspivid. Sia in raspivid che in picamera, l'impostazione predefinita è 17 Mbps (megabit al secondo), quindi teoricamente un video di 24 ore registrato con l'impostazione predefinita non potrebbe essere maggiore di:

  24         hours
* 60         minutes per hour
* 60         seconds per minute
* 17000000   bits per second
/ 8          bits per byte
/ 1073741824 bytes per gig
  ----------
  170.990825 Gb

Hmm ... è più grande di quanto mi aspettassi, ma va bene. Una cosa da tenere a mente è che l'impostazione predefinita di 17 Mbps è utile per la risoluzione di registrazione predefinita, che è di 1080p nel caso di raspivid (sebbene Picamera sia impostata automaticamente sulla risoluzione dello schermo o 720p nel caso di nessuna visualizzazione come quella sembrava "più amichevole" quando l'ho scritto). Se stai registrando solo a 360p, probabilmente puoi cavartela con un limite di bitrate molto più basso.

L'altra cosa da tenere a mente è che il limite di bitrate è proprio questo: un limite superiore. Se l'encoder non ha bisogno di tutti i 17 milioni di bit per produrre una rappresentazione abbastanza buona del movimento di un secondo, non ne utilizzerà molti. qualitySfogliando la quantizzazione dell'encoder (che è il parametro in picamera, e il--qpparametro in raspivid) possiamo anche regolare l'idea dell'encoder sul significato di "abbastanza buono". La qualità è rappresentata da un valore compreso tra 0 e 40. Valori più bassi significano una qualità migliore, quindi 1 è follemente buono e 40 è ridicolmente cattivo. I valori "abbastanza buoni" sono circa 20-25. Il valore 0 (che è anche il valore predefinito) sembra essere speciale; Non sono sicuro di cosa significhi esattamente per l'encoder (dovresti chiedere agli sviluppatori del firmware che), ma sembra produrre una qualità simile a valori intorno ai 15-20 (cioè molto buoni).

Quindi, ipotizzando una qualità media (diciamo 20), che tipo di bitrate è necessario per registrare video a 360p a schermo largo? Ho eseguito la seguente riga di comando raspiva due volte per registrare 30 secondi di video, quindi ho trascorso la prima registrazione agitando la telecamera (supponendo che più movimento significa maggiore larghezza di banda richiesta e vogliamo testare i limiti qui) e il secondo con la scena assolutamente statica:

raspivid --width 640 --height 360 --framerate 24 --bitrate 17000000 --qp 20 --timeout 30000 --output test.h264

I file risultanti erano 673675 byte (658 KB) e 2804555 byte (2,7 Mb) di dimensione rispettivamente, quindi i bitrate prodotti dall'encoder erano:

  673675   bytes
* 8        bits per byte
/ 30       seconds
  --------
  179646.6 bits per second (static scene)

  2804555  bytes
* 8        bits per byte
/ 30       seconds
  --------
  747881.3 bits per second (full motion scene)

Quindi, inserendo questi valori nell'equazione sopra, possiamo realisticamente aspettarci che video di 24 ore valgano un valore simile utilizzando impostazioni simili tra 1,8 Gb e 7,5 Gb. Possiamo assicurarci che sicuramente non sarà più grande di quello impostando il bitrate su qualcosa come 750000 che sappiamo darà all'encoder abbastanza spazio per riprodurre il movimento con la qualità desiderata (20), oppure potresti sperimentare qualità inferiori (ad es. 25 ) per vedere se sarebbero accettabili, quindi abbassare di conseguenza il limite di bitrate. Detto questo, vale la pena ricordare che è probabile che si rompa 2Gb con il file, quindi, come menzionato sopra, è probabile che si verifichi il problema del puntatore del file a 64 bit a meno che non si usi Python o ricompilare l'area utente.

Per riferimento, ecco lo script Python dall'alto modificato per includere i limiti appena discussi:

import picamera

with picamera.PiCamera() as camera:
    camera.resolution = (640, 360)
    camera.framerate = 24
    camera.start_recording('one_day.h264', quality=20, bitrate=750000)
    camera.wait_recording(24 * 60 * 60)
    camera.stop_recording()

Infine, solo per rispondere al commento dei goldilock sulla risposta di Linus: dividere il file video in più parti è abbastanza semplice (e allevierebbe facilmente qualsiasi problema relativo al puntatore di file a 64 bit). Con raspivid, è possibile utilizzare il --segmentparametro per specificare che un nuovo file deve essere aperto ogni n millisecondi, ad esempio per registrare un file per ogni ora ( %02dil nome del file verrà sostituito con un numero, ad esempio 01, 02, 03, .. .):

raspivid --width 640 --height 360 --framerate 24 --bitrate 750000 --qp 20 --timeout $((24*60*60*1000)) --segment $((1*60*60*1000)) --output hour%02d.h264

In alternativa, con Picamera è possibile utilizzare il metodo record_sequence per suddividere in base al tempo:

import picamera

with picamera.PiCamera() as camera:
    camera.resolution = (640, 360)
    camera.framerate = 24
    for filename in camera.record_sequence([
            'hour%02d.h264' % (h + 1)
            for h in range(24)
            ], quality=20, bitrate=750000):
        camera.wait_recording(60 * 60)

O in base alla dimensione del file. Nell'esempio seguente, l'ho impostato per produrre 100 file in rotazione ogni volta che raggiungono> 1Mb e ho messo l'iteratore di output nella sua funzione solo per dimostrare che è possibile utilizzare infiniti iteratori record_sequenceanche con :

import io
import itertools
import picamera

def outputs():
    for i in itertools.count(1):
        yield io.open('file%02d.h264' % i, 'wb')

with picamera.PiCamera() as camera:
    camera.resolution = (640, 360)
    camera.framerate = 24
    for output in camera.record_sequence(
            outputs(), quality=20, bitrate=750000):
        while output.tell() < 1048576:
            camera.wait_recording(0.1)
        if output.name == 'file99.h264':
            break

O ... beh, qualunque limite tu possa pensare al codice per!


+1 Ho modificato la tua risposta altrimenti spettacolare per includere l'evidenziazione della sintassi.
Jacobm001

Ah, grazie - probabilmente dovrei imparare un po 'di più della variante MD di SO ad un certo punto ...
Dave Jones,

3

Se stai usando raspivid per registrare è "possibile", c'è stata una patch per supportare file di grandi dimensioni, dove la dimensione> 2 GB ( -D_FILE_OFFSET_BITS=64è richiesta nei flag forniti a gcc). Tuttavia è necessario compilare l'userland fonte da soli.

Va notato tuttavia, si dovrebbe essere molto attenti, perché se si riempie la partizione di sistema su Linux, può verificarsi un comportamento molto brutto. Quindi dovresti creare una partizione separata per i tuoi lunghi video.

Potrebbe anche essere una buona idea ridurre la velocità in bit in caso di problemi con le dimensioni del file.


4
Se è accettabile, è anche possibile eseguire uno script intermittente (ad es. Via cron) per interrompere il raspividprocesso corrente , eseguire il rollover del file di output e avviarlo di nuovo, in modo da finire con una serie di file più piccoli che rappresentano specifici intervalli di tempo.
Riccioli d'oro
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.