Spela in gråskaligt övervakningssystem med YPbPr?

Om man har tre svartvita cctv-kameror som matar ut komponentvideo och den enda infångstkällan som finns till hands har kan ta emot YPbPr (röd, blå, grön), har man då verkligen möjlighet att lagra tre videoströmmar som separata kanaler? Jag har för mig att det borde fungera med två åtminstone.

Om kamerorna är synkroniserade ( så att de är på samma pixel samtdiigt ) borde det teoretiskt gå.

Annars går det inte.

Ja kamerorna har inte någon inbyggd genlock så då handlar det väl om att få till någon extern bildsynkronisering. Hittar bara frame synchronizers från 20 papp och uppåt så det går bort.
Finns det några enkla kretsar för TBC man kan använda för att synkronisera videokällorna utan att behöva köpa en hel videomixer?

Att göra tidkorrigeringen i den analoga domänen är inte enkelt eller billigt.

Om kamerorna är riktigt gamla analoga kameror så kanske det hade gått att bygga om dem så att de trots allt fick genlock. Fast då måste du dra dubbelt så mycket kabel och kablarna måste vara lika långa till alla kameror.

Det kommer att ta mycket tid och kosta en hel del pengar.

En annan variant är att bygga sin egen frame sync i den digitala domänen genom att ha en liten dator med tre analoga ingångar, ett program som synkroniserar detta och sen sänder ut det på en analog utgång...


Varför vill du använda just dessa kameror och vad är det du egentligen vill åstadkomma?

I stort sett alla FPV-kameror är analoga. Det här är en hat till Raspberry pi som har just ybprb infångst.
https://lintestsystems.com/

Tanken med att använda tre kameror är att du skulle kunna använda två fram som är riktade i 45 graders vinkel från varandra och en som backspegel. Så att man får ett bredare synfält. Fördelen med att göra detta monokromt är att du kan få ned bandbredden på de individuella kanalerna och fördelen med att använda raspberry pi är att med spi-interfacet så får du en väldigt kort delay på själva signalbehandlandet för relativt sett lite pengar.

Det finns ingen färdig lösning för att mixa fler bildkällor för portabelt bruk idag. Det finns 3D-kameror, men det är inte specifikt vad jag försöker åstakomma.

Det här är en monokrom fpv-kamera som dessutom har väldigt hög ljuskänslighet.

http://shop.runcam.com/runcam-owl/

Ah, nu klarnar bilden () på vad det är du vill göra.


När jag tittar på kretskortet ser jag att det står CVBS-1, CVBS-2 och CVBS-3 och att kortet har stöd för att fånga från olika källor.

Frågan är hur man får ut data från kortet. Om det går att ställa i RAW-läge, så att du kan läsa av vad AD-omvandlarna får in på ingångarna, kan det vara en lösning, för då kan du göra synkroniseringen digitalt.

Om jag förstår dig rätt så ska detta sättas på en drone av något slag, så vikten, ström och storlek har betydelse.

Om kortet inte går att ställa i RAW-läge, är en annan variant att snabbt skifta mellan kamerorna. Du får en lägre framerate, men kan använda flera kameror.

Alternativt får du skaffa flera sådana kort.


Hur är tanken att skicka vidare bilden efter att du fått in den i din Raspberry?

Att gå ifrån 25 bildrutor per sekund till 8.3 skulle inte leda till någon fördjupad inlevelse, snarare tvärt om.
Har den inte möjlighet till att ställas om till raw-läge är det nog helt enkelt någon a/d lösning man får kolla på.
Det finns dvr-system som används paralellt med de analoga sändarna idag. Hela pal/ntsc signalen får plats pä en 20 Mhz kanal. Frågan är om man digitalt får plats med tre gånger så mycket information och kan göra det med lika låg fördröjning...

Det hade som sagt underlättat om du berättade lite mer detaljerat vad det är du vill åstadkomma.



Den borde få plats på en 8MHz kanal, tycker jag.


Inte med lika låg fördröjning och lägre bandbredd. Det är tyvärr omöjligt.

Surround teleprescense från ombord på en drönare som har nightvision.

En vanlig surround setup innebär att man har tre skärmar, där två av dem är vinklade åt sidorna.

https://i.ytimg.com/vi/GP2rsMbqrfM/maxresdefault.jpg
http://imgur.com/digxEu2


Även om kameran skickar en svartvit bild så är det ju fortfarande en helt okomprimerad kompositvideosignal som skickas.

https://sv.wikipedia.org/wiki/Phase_...C3.A4rgkodning
https://en.wikipedia.org/wiki/PAL#Colour_encoding
https://en.wikipedia.org/wiki/Composite_video

Även känt som LDTV

https://en.wikipedia.org/wiki/Low-definition_television.

Dvs hälften av vad kameran faktiskt skickar ut kan man kasta bort.
Resten kan man köra videokomprimering på.

De helt analoga systemen idag har en fördröjning på omkring 70-80 ms mellan kameran, moduleringen av signalen till radio och att det visas upp i headsetet. Det är omkring 2-2,5 bildrutors fördröjning. När man snackar om spel så är fördröjningar som ligger under 200 ms märkbara men brukar inte beskrivas som distraherande så vi har på kretsnivå en hel evighet av processtid att bolla med.

Säg att man budgeterar signalbehandling och komprimering till 2 eller 3 bildrutor till.

Jag vill ha tre strömmar gråskalig 576i alternativt 480i video komprimerad till mpeg4.

https://en.wikipedia.org/wiki/576i
https://en.wikipedia.org/wiki/480i

Kör man bara de hela fälten så blir upplösningen 352 × 240 för NTSC och 352 × 288 för PAL.
Sen kanske man inte behöver ha alla 50 eller 60 bildrutorna det blir heller, 30 fps brukar anses vara spelbart, men säg 35-40 för att man skall känna att det flyter på åtminstone.

Okomprimerade videoströmmar (råformat) i fullfärg tar jättestor bandbredd, signalbehandlad och komprimerad svartvit video i låg upplösning borde man få plats med betydligt fler strömmar av på samma mängd bandbredd.

Skulle inte förvåna mig det minsta ifall FPV-folket redan har kommit på det här och aktivt jobbar för att få a/d inbyggt i kommande FPV-kameror, även färgvideo skulle man kunna få fördelar av att kunna komprimera on the go.
Man skulle kunna skicka samma signal i MIMO (fler uppsättningar) och minska risken för störningar bl.a.

Det var ju denna platsbesparing i bandbredden som gjorde att man övergick från analog till digital marksänd tv.

I det marksända analoga tv-nätet fick det plats med c:a 8 stycken när vi hade som mest.

Idag går det såhär många i samma kabel.

https://sv.wikipedia.org/wiki/Marks%...verige#Kanaler

Idag har man på många platser dock eftersändning av digitala kanaler som analoga hos många bostadsbolag, men det analoga nätet är nedsläckt sedan 2007.

Ja, och för en kanal borde 8MHz vara tillräckligt: https://en.wikipedia.org/wiki/File:Pal_channel.svg


Du bör ju köra med den framerate som kameran har. Om du tappar frames bilr det hackigt.



Man skulle kunna tro det, men med PAL är så inte fallet. Den analoga PAL-signalen skulle vara kompatibel med befintliga gråskale-apparater, så i korthet blandas alla tre färgkanalerna ihop till en luminans-kanal. Färginformationen är av lägre upplösning, och ligger på en subcarrier i signalen. Så färginformationen tar inte så mycket plats som man tror.




Jo, men det gjorde på bekostnad av att signalen blev fördröjd då den behöver komprimeras.
SVT funderade på att ta bort klockan ur testbilden, eftersom den kunde visa fel på grund av olika fördröjningar.

Jag blir inte riktigt klok på vilken nivå du vill lägga detta.

Om du digitaliserar signalerna kan du komprimera dem hårt.

Nu kommer nästa problem: synkroniseringen.
Om du behandlar det som separata dataströmmar kommer du att få problem.

Jag gissar att du är ute efter att göra en sändar-modul som sitter på drönaren och sedan en mottagare.

Ett sätt att hålla synkroniseringen är att lägga bilden från alla kamerorna under varandra:
Om varje kamera genererar en 352 × 288 bild, så lägger du ihop det digital till en 352 × 864 bild som sedan komprimeras och skickas över länken. I mottagaren kan du sedan separera det.

Några fördelar är att:
* bilderna är alltid synkroniserade
* bilderna är av högsta möjliga kvalité
* mpeg-kodningen kan dra nytta av hur saker rör sig.

På 8 Mhz har du inbakat utrymme för såväl krominans som ljud.

Demodulerat blir det 50 eller 60 hz färg video med stereoljud.


Det är isf en kompromiss som skulle korta ned arbetet med att komprimera video. Om folk upplever spel som spelbara vid 30 bilder per sekund så nog borde väl en flygsimulator som används för fjärrstyrning upplevas som spelbar.



Hmm... jo jag har för mig att man använder sig av samma teknik i jpeg-standarden. Den bygger på att vi har svårare att uppleva färgskillnader än ljusskilnader. Märkligt nog har vi en ständigt efterfrågan på att utöka bitdjupet i såväl skärmar som videostandarder...




Det beror helt på vilken efterfrågan det finns.

Tänker mig ett proof of concept och därefter typ kickstarter eller gofundme.
En mockup behöver inte innehålla en färdig produkt bara tydligt förklara vad den färdiga produkten är tänkt att göra.

När SVT började med sina digitalsändningar så hade inte tekniken kommit särskilt långt.
Idag kan du använda fpga-lösningar för att komprimera 1080p till H264 med väldigt kort fördröjning.

Den här fixar t.ex 1080p 30fps på samma fördröjning som 1/8 bildruta tar.

https://www.altera.com/content/dam/a...ow-latency.pdf

Finns i det här SoC-kortet, har inte letat många sekunder för att hitta det skall det tilläggas.
Går säkert att få tag i billigare,

http://www.enclustra.com/en/products...FQnGsgoddhcEtg


Det är nog här det tunga lyftandet måste börja för de små grå under skalpen,,,
Panoramafilmning har nog många år på nacken, jag måste nog börja med att göra research på hur andra har gått till väga.

Sändare och mottagare finns färdiga att köpa, t.om de som fixar 1080p sändningar, men skall jag göra ett helt eget videoformat måste jag nog göra en egen codec... Blir nog enklast att skala upp bilden.

edit: Som jag misstänkte så finns det digitala fpv-kameror som är under utveckling och man använder även som jag misstänkte högre upplösning, lägre latens och högre bildfrekvens,

https://fpv.blue/

https://fpv.blue/2016/07/glass-to-gl...-milliseconds/