Jag måste erkänna att jag inte var medveten om 2Gb-begränsningen i raspividens lagerbyggnad (nämns i Linus svar). Ett alternativ (om du inte gillar att kompilera om användarland) är att använda picamera (Python stöder 64-bitars filpekare ur lådan). Följande bör till exempel spela in en 360p-video i bredbild i H.264 med glädje i 24 timmar:

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

Nästa del av frågan är om det passar på ett 64 GB SD-kort. Min aning är "förmodligen", men låt oss verifiera att ...

Pi: s H.264-kodare kan ges en bithastighetsgräns med parametern bitrate i picameras start_recording -metoden eller parametern --bitrate i raspivid. I både raspivid och picamera är detta som standard 17Mbps (megabit per sekund) så teoretiskt kan en 24-timmars video inspelad med standardinställningen inte vara större än:

  24 timmar * 60 minuter per timme * 60 sekunder per minut * 17000000 bitar per sekund / 8 bitar per byte / 1073741824 byte per gig ---------- 170.990825 Gb  

Hmm ... det är större än jag förväntade mig, men okej. En sak att komma ihåg är att standardvärdet på 17 Mbps är tänkt att vara användbart vid standardinspelningsupplösningen, vilket är full 1080p när det gäller raspivid (även om picamera är standard för skärmupplösningen eller 720p om det inte finns någon bildskärm. verkade "vänligare" när jag skrev det). Om du bara spelar in på 360p kan du förmodligen komma undan med en mycket lägre bithastighetsgräns.

Den andra saken att tänka på är att bithastighetsgränsen är just det: en övre gräns. Om kodaren inte behöver alla 17 miljoner bitar för att producera en tillräckligt bra representation av en sekunds rörelse, kommer den inte att använda så många. Genom att fisa med kodarens kvantisering (som är kvalitet -parametern i picamera och --qp -parametern i raspivid) kan vi också justera kodarens idé om vad som är "tillräckligt bra " betyder. Kvaliteten representeras av ett värde mellan 0 och 40. Lägre värden betyder bättre kvalitet, så 1 är vansinnigt bra och 40 är löjligt dåligt. Typiska "tillräckligt bra" värden ligger runt 20-25. Värdet 0 (som också är standard) verkar vara speciellt; Jag är inte säker på exakt vad det betyder för kodaren (du måste fråga firmware-devs det), men det verkar ge liknande kvalitet som värden runt 15-20 (dvs. mycket bra).

Så, antagande av genomsnittlig kvalitet (låt oss säga 20), vilken typ av bithastighet behöver vi för att spela in bredbilds 360p video? Jag sprang följande rasande kommandorad två gånger för att spela in video i 30 sekunder och spenderade sedan den första inspelningen med att vifta med kameran (under antagandet att mer rörelse betyder mer bandbredd, och vi vill testa gränserna här), och den andra med scenen helt statisk:

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

De resulterande filerna var 673675 byte (658Kb) och 2804555 byte (2,7Mb) i storlek, så bitfrekvensen som skapades av kodaren var:

  673675 byte * 8 bitar per byte / 30 sekunder -------- 179646,6 bitar per sekund (statisk scen) 2804555 byte * 8 bitar per byte / 30 sekunder ------- - 747881,3 bitar per sekund (scen i full rörelse)  

Därför kan vi realistiskt förvänta oss 24 timmars video med liknande inställningar för att komma in någonstans mellan 1,8 GB och 7,5 GB i storlek genom att koppla in dessa värden i ekvationen ovan. Vi kan se till att det definitivt inte blir större än så genom att ställa in bithastighet till något som 750000 vilket vi vet kommer att ge kodaren tillräckligt med utrymme för att reproducera rörelse i önskad kvalitet (20), eller så kan du experimentera med lägre kvaliteter (t.ex. 25 ) för att se om de skulle vara acceptabla och sedan sänka bithastighetsgränsen därefter. Med det sagt är det värt att komma ihåg att det är troligt att du bryter 2Gb med filen, så som nämnts ovan kommer du sannolikt att stöta på 64-bitars filpekaren, såvida du inte använder Python eller kompilerar användarlandet igen.

För referens, här är Python-skriptet ovanifrån modifierat för att inkludera gränserna som just diskuterats:

  importera picamerawith picamera.PiCamera () som kamera : 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 ()  kod> 

Slutligen, bara för att svara på goldilocks kommentar på Linus svar: att dela upp videofilen i flera delar är ganska lätt (och skulle lätt kunna lindra alla problem med 64-bitars filpekare). Med raspivid kan du använda parametern --segment för att ange att en ny fil ska öppnas varje n millisekund, t.ex. för att spela in en fil för varje timme (% 02d i filnamnet kommer att ersättas med ett nummer, t.ex. 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 timme% 02d.h264  

Alternativt kan du med picamera använda metoden record_sequence för att dela ut baserat på tid:

  importera picamera
med picamera.PiCamera () som kamera: camera.resolution = (640, 360) camera.framerate = 24 för filnamn i kamera.record_sequence (['hour% 02d.h264'% (h + 1) for h in range (24 )], quality = 20, bitrate = 750000): camera.wait_recording (60 * 60)  

Eller baserat på filstorlek. I exemplet nedan har jag ställt in det för att producera 100 filer som rullar över när var och en når> 1Mb, och placerade utgångs-iteratorn i sin egen funktion bara för att visa att det är möjligt att använda oändliga iteratorer med record_sequence också :

  importera ioimport itertoolsimport picameradef-utgångar (): för i i itertools.count (1): ge io.open ('fil% 02d.h264 '% i,' wb ') med picamera.PiCamera () som kamera: camera.resolution = (640, 360) camera.framerate = 24 för utdata i kamera. record_sequence (utgångar (), kvalitet = 20, bitrate = 750000) : medan output.tell () < 1048576: camera.wait_recording (0.1) om output.name == 'file99.h264': bryta  

Eller ... ja, vilken gräns du kan tänk på koden för!

Om du använder raspivid för att spela in är det "möjligt", det har funnits en korrigeringsfil för att stödja stora filer, där storleken> 2 GB ( -D_FILE_OFFSET_BITS = 64 krävs i flaggor som levereras till gcc). Du måste dock kompilera källan userland själv.

Det bör dock noteras, du bör vara mycket försiktig, för om du fyller i systempartitionen på Linux är det mycket dåligt kan uppträda. Så du bör skapa en separat partition för dina långa videor.

Det kan också vara en bra idé att minska bithastigheten om du har problem med filstorleken.