Puis-je enregistrer une vidéo de 24 heures sur le Raspberry Pi avec module caméra?

Étant donné que j'ai une carte SD avec une capacité suffisante, est-il théoriquement possible d'enregistrer une vidéo de 24 heures avec un module de caméra ou la durée d'enregistrement est-elle limitée? Quelqu'un at-il essayé cela?

Pensez-vous que 64 Go suffisent pour une qualité d'enregistrement 360p?

Je dois admettre que je n'étais pas au courant de la limitation de 2 Go dans la constitution de stock de raspivid (mentionnée dans la réponse de Linus). Une alternative (si vous n'avez pas envie de recompiler l'espace utilisateur) serait d'utiliser picamera (Python prend en charge les pointeurs de fichiers 64 bits prêts à l'emploi ). Par exemple, ce qui suit devrait enregistrer une vidéo 360p grand écran en H.264 avec bonheur pendant 24 heures:

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 prochaine partie de la question est de savoir si cela conviendra à une carte SD de 64 Go. Mon intuition est "probablement", mais vérifions que ...

L'encodeur H.264 du Pi peut recevoir une limite de débit binaire avec le bitrateparamètre de la méthode start_recording de picamera , ou le --bitrateparamètre en raspivid. En raspivid et en picamera, cette valeur par défaut est de 17 Mbps (mégabits par seconde), donc théoriquement une vidéo de 24 heures enregistrée avec le paramètre par défaut ne peut pas être plus grande que:

  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 ... c'est plus grand que ce à quoi je m'attendais, mais d'accord. Une chose à garder à l'esprit est que la valeur par défaut de 17 Mbps est censée être utile à la résolution d'enregistrement par défaut, qui est pleine 1080p dans le cas de raspivid (bien que picamera par défaut à la résolution d'affichage ou 720p dans le cas d'aucun affichage comme cela semblait "plus convivial" quand je l'ai écrit). Si vous enregistrez uniquement à 360p, vous pouvez probablement vous en sortir avec une limite de débit binaire beaucoup plus faible.

L'autre chose à garder à l'esprit est que la limite de débit est juste cela: une limite supérieure. Si l'encodeur n'a pas besoin des 17 millions de bits pour produire une représentation suffisamment bonne de la valeur d'une seconde de mouvement, il n'en utilisera pas autant. En jouant avec la quantification de l'encodeur (qui est le qualityparamètre en picamera, et le--qpparamètre en raspivid), nous pouvons également ajuster l'idée de l'encodeur de ce que signifie "assez bon". La qualité est représentée par une valeur entre 0 et 40. Des valeurs plus faibles signifient une meilleure qualité, donc 1 est incroyablement bon, et 40 est ridiculement mauvais. Les valeurs "assez bonnes" typiques sont d'environ 20-25. La valeur 0 (qui est également la valeur par défaut) semble être spéciale; Je ne sais pas exactement ce que cela signifie pour l'encodeur (il faudrait demander cela aux développeurs du firmware), mais il semble produire une qualité similaire à des valeurs autour de 15-20 (c'est-à-dire très bonne).

Donc, en supposant une qualité moyenne (disons 20), quel type de débit avons-nous besoin pour enregistrer une vidéo 360p grand écran? J'ai exécuté la ligne de commande raspivid suivante deux fois pour enregistrer 30 secondes de vidéo, puis j'ai passé le premier enregistrement en agitant la caméra (en supposant que plus de mouvement signifie plus de bande passante requise, et nous voulons tester les limites ici), et la seconde avec la scène absolument statique:

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

La taille des fichiers résultants était respectivement de 673675 octets (658 Ko) et 2804555 octets (2,7 Mo), de sorte que les débits binaires produits par l'encodeur étaient les suivants:

  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)

Par conséquent, en branchant ces valeurs dans l'équation ci-dessus, nous pouvons raisonnablement nous attendre à ce que 24 heures de vidéo utilisant des paramètres similaires se situent entre 1,8 Go et 7,5 Go. Nous pouvons nous assurer qu'il ne sera certainement pas plus grand que cela en réglant le débit sur quelque chose comme 750000 qui, nous le savons, donnera à l'encodeur assez de place pour reproduire le mouvement à la qualité souhaitée (20), ou vous pouvez expérimenter avec des qualités inférieures (par exemple 25 ) pour voir s'ils seraient acceptables, puis abaisser la limite de débit en conséquence. Cela dit, il convient de garder à l'esprit que vous risquez de casser 2 Go avec le fichier, donc comme mentionné ci-dessus, vous risquez de rencontrer le problème du pointeur de fichier 64 bits, sauf si vous utilisez Python ou recompilez l'espace utilisateur.

Pour référence, voici le script Python ci-dessus modifié pour inclure les limites qui viennent d'être discutées:

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()

Enfin, juste pour répondre au commentaire de goldilocks sur la réponse de Linus: la division du fichier vidéo en plusieurs parties est assez facile (et atténuerait facilement tout problème de pointeur de fichier 64 bits). Avec raspivid, vous pouvez utiliser le --segmentparamètre pour spécifier qu'un nouveau fichier doit être ouvert toutes les n millisecondes, par exemple pour enregistrer un fichier pour chaque heure (le %02ddans le nom de fichier sera remplacé par un nombre, par exemple 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

Alternativement, avec picamera, vous pouvez utiliser la méthode record_sequence pour diviser en fonction du temps:

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)

Ou basé sur la taille du fichier. Dans l'exemple ci-dessous, je l'ai configuré pour produire 100 fichiers en survolant une fois que chacun atteint> 1 Mo, et j'ai placé l'itérateur de sortie dans sa propre fonction juste pour démontrer qu'il est possible d'utiliser des itérateurs infinis avec record_sequence:

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

Ou bien, quelle que soit la limite pour laquelle vous pouvez penser au code!

Si vous utilisez raspivid pour enregistrer, il est "possible", il y a eu un correctif pour prendre en charge les fichiers volumineux, dont la taille> 2 Go ( -D_FILE_OFFSET_BITS=64est requis dans les drapeaux fournis à gcc). Cependant, vous devez compiler vous-même la source de l' espace utilisateur .

Il convient toutefois de noter que vous devez être très prudent, car si vous remplissez la partition système sous Linux, un très mauvais comportement peut se produire. Vous devez donc créer une partition séparée pour vos longues vidéos.

Il peut également être judicieux de réduire le débit binaire si vous rencontrez des problèmes avec la taille du fichier.