videokamera->ADC->uC->DAC->Tv

[sysshad]

Hejsan alla pulare, tänkte kolla om någon har labbat runt med att försöka på nått sätt digitalisera en Composit video signal från typ en liten videokameramodul så en mikrodator sedan kan skicka denna information till en DA omvandlare och sedan så kan man se bilden igen på en RCA composit tv ingång

Ide'en är väl att kolla om man kan göra detta med en composit signal eller s-video... samt att på så sätt kanske bygga någon form av övervakningsstation med uC'n för flera kameror och kunna sända videosignalen kanske ev också trådlöst mellan två st uC.

Nått att bita i kanske

[xxargs]

Ja,definivt något att bita i då det handlar om ca 350 Mbit data i sekunden som skall transporteras om man inte komprimerar och dekomprimerar frames i processen invid A/D och D/A-omvandlarna med någon FPGA/hårdvaru codec/decoder för video..

USB2.0 kan du glömma utan det är Firewire/1394 som gäller om du skall skyffla video i råformat från captureenheten in i datorn - 1394 är nämligen byggd för att kunna hantera audio och videoströmmar i realtid och har därmed DMA-support för autonom datatransport utan så mycket CPU-förbrukning.

USB2.0 är PIO-driven och kräver 100% CPU-allokering vid full datakapacitet vilket gör att det blir korta avbrott hela tiden vid OS:s housekeeping, diskskrivning etc. och man får tappade frames hur man än gör - och defintivt så hinner man inte med någon mjukvarukomprimering om man samtidigt skall skyffla 350 Mbit/s data från USB2.0

...

Skall du ens fundera på detta så börja med att försöka captura video med din dator och capturekort för att se ur det fungerar - det är knepigt nog och slukar oehörda mängder med hårddiskutrymme om inte capturekortet leverera i Mpeg2 eller Mpeg4-format direkt.

Har du ett enkelt BT8x8-kort så hinner du mjukvarukomprimera på sin höjd MJPEG eller huffyuv innan du lägger på hårddisken då CPU på 3 GHz inte hinner med att komprimera i mpeg2 eller mpeg4 i realtid och med kvalitet utan tappade frames, och då handlar det om ca 10 GByte per timme i hårdiskutrymme vid 720x576x25 Mjpeg kodning och ca 30 GByte per timme om det komprimeras med huffyuv - det är alltså inget svårt att fylla upp en 750 GB hårddisk på kort tid om man captura video...

med dessa mängder så inser du snart att trådlös Wlan inte är något alternativ om du tänker transportera lågkomprimerad video - inte ens 100 Mbit Ethernet räcker för detta...

[blueint]

Jag har komprimerat till mpeg4 2-4 Mbps i realtid med en AMD Athlon XP1800 + PCI32/33 Bt8x8 kort. Det kan bli framedrop någon gång i halvtimmen. Kör FreeBSD då

[bearing]

350 Mbit? är dett full-hd du pratar om?

720*576px * 8bit/px * 25Hz = 82 Mbit

Jag tror det blir ungefär samma kvalitet i 360x288 - 20 Mbit, eftersom 720x576 är framräknade från bayermönstret i sensorn. För varje färg används egentligen 4 pixlar.

[sysshad]

Hejsan alla, tack för visat intresse.
Det är bara enkel S-video signal jag funderar på att göra denna koppling med, inget HD eller annan video som kräver stor överföringshastighet. Och när man pratar mb/s så pratar man binärt dvs digitalt. Det jag är ute efter är helt enkelt bara frekvesen den analoga som skall komma ur s-video.

Än så länge funderar jag fortfarande på om inte det skall gå att göra, det man behöver veta är väl
* hur stor bandbredd en s-video signal har
* vilken frekvens den jobbar på

dessa faktorer borde väl avgöra i huvudsak för hur denna koppling med ADC -> uC -> DAC skall fungera, är det ingen som testat detta

/§ysshad

[bearing]

Jag tror det blir svårt för en vanlig enkel uC att hinna med som mellansteg.

S-video har väl en signal för varje komponent + synkning i kompositsignalen, så då behövs ju flera ADC.

[xxargs]

sysshad:

När det gäller videosignalen så får du räkna med minst 5.5 MHz bandbredd i bildsignalen för den svartvita delen, med andra ord minst 11 megasampel på din AD-omvandlare. Skall du sampla från composite direkt så är det mer komplicerat eftersom du har färgbärvåg i överkanten (4.43 MHz ?) och dess informationssidband nedåt i det svartvita informationssidabanden till nära halva frekvensområdet. Färg och SV är inflätat i varandra, men från varsin håll sas. - och dom har tendens att interferera med varandra i enklare mottagare, det är det som ger rullande färger i täta svartvitrandiga mönster på TV utan avancerad dekoder (med kamfilter etc. som bara återfinns hos S-VIDEO videobandspelare och proffsutrustning).

Om du vill ha suddig videospelarkvalitet så kanske du kan gå ned till 3.5 MHz bandbredd (7 Megasampel - men bara SV och förmodligen måste du ha antialisingfilter som skär tvärt vid 3.5 MHz

Tar du signale från S-VIDEO så är Luma (SV) och krominans uppdelat, nöjer du med SV så tar du bara luminasdelen.

Med bandbredd så menar man här från DC (egentligen 50 Hz) till 5.5 MHz

Bearing:

HD är för mig är 1920x1080 i upplösning

Normal TV-upplösning är 768x576 om man skall ha fyrkantiga pixel på PAL-systemet, Men för att man skulle kunna ha samma kristall till videokretsarna även för de amerikanska systemen med annan framerate och linjetal så blev pixlana något rektagulära med 720 pixel horisontalled, annars gick inte delningstalen mot kristalle jämt upp....


720x576 är _inte_ HD - även om filmerna på internet har kallats så, och med jämförelse med NTSC så är de klart skarpare.

360x288 ?? - är det någon som använder så låg upplösning längre??? - detta hör till MPEG1-världen där man blandade eller slängde bort hälften av TV-linjerna innan kodning. Man var tvungen att skapa MPEG2-standarden just för att kunna hantera en standard TV-bild med alla scanlinjer då den stora förändringen till MPEG2 var just dubbla antalet linjer och hantera Interlace för att övh. accepteras inom TV-broadcast världen (läs DVD-skivor) - det klarar nämligen inte MPEG1.

till och med den sunkigaste av alla VHS-spelare har 576 Linjer upplösning i vertikalled - inte 288 linjer som i MPEG1 som är att klassa som ännu sämre än den sämsta av VHS-videospelaren i upplösning.


82 Mbit/s fungerar för en färg, du måste 3-dubbla detta för färgbilder - det blir ungefär 31.1 Mbyte per sekund att hantera i RGB-rymd.

själv har jag upptäckt att när man spelar in analogvideo så räcker det inte med 8-bitars upplösning per färg utan det behövs snarar 12 Bitar om inte djupskuggorna skall bli väl stegiga om man inte samtidigt vill få utbrända högdagrar. Moderna videocapturekort har också 10-12 bitars A/D-omvandlare.

[blueint]

Analog RGB dekoder + 3x A/D omvandlare med LVDS interface + FPGA är nog det som gäller. En uC har inte en chans i dom här hastigheterna om inte någon hårdvara hanterar och buffrar videodata och processorn är på minst 500 MHz eller mer.
En annan lösning är att köpa ett PCI bildfångarkort model Bt878.

[sysshad]

Hejsan igen, tack för alla kanonbra svar, har verkligen fått mig att inse det var klurigare än jag först trodde.

En ide' som detta bygge eventuellt skulle ha tillämpats på, var att ha en liten kamera med composit som via mikrodator skickade signalen trådlöst via t.ex. Kjell&Co 433Mhz radiosändare till en annan mikrodator med likadan mottagare.
Men det slog mig, varför måste jag skicka det genom uC och da/ad converters egentligen - var väl mest en undring om det gick antar jag
Är nog lättare i detta fall att hitta någon billig videosändare istället, oftast finns ju lösningarna till allt man vill göra redan, men det är ju oftast alltid roligare att bygga själv

/§ysshad

[hcb]

Om du bara skall skicka signalen vidare borde du kunna ta vilken videosändare som helst från Clas, Kjell eller Teknikmagasinet. Jämfört med det du skissade på i första posten blir det nog både lättare och billigare...

[xxargs]

Dock kan du glömma 433 Mhz då videosignalen är vida mycket större än vad som är tillåtet inom 433 MHz. det är inte utan orsak som hela området 470 - 850MHz av myndigheter är och var allokerad för just bara TV. - området som telebolagen nu kastar lystna blickar då man kan få lite räckvidd här med fortfarande acceptabelt små antenner - att gå över 1800 - 2100 MHz är nämligen inte lönt/möjlig om man vill ha lite större celler.

Det här att man flätar ihop SV och färgsignal är en av metoderna på att minska bandbredd i luften. Mycket möda har tänkts på detta med för tiden tillgänglig teknik (60-talet) - man använde också I-Q-modulering i färgsignalen för att få med 2 kanaler i samma signal (U,V) tillsamman med Y som är luman, bygger upp färgbilden. Att man använder YUV-färgrymd istället för RGB i TV-sammanng beror på att den är mycket snålare med bandbredd för samma upplevda kvalitet än om man skulle försöka med RGB, mycket beroende på att man i YUV-mode kan man lågpassfiltrera U,V-delen för sig (dvs färgdelen) utan att det syns så mycket i färgbilden - våra ögon har nämligen lägre upplösning för färg är svartvita kontraster och reagerar inte så mycket för färgutsmetning över dom skarpa SV-kontrasterna - man kan säga att man på analog sätt har kompirmerat TV-signalen avsevärt ur bandbreddsynpunkt utan att ögar reagerar så mycket - det mpeg och jpeg gör är bara lite förfinat, om man bortser från mosaiktedenserna då...

Kanalindelningen på TV-banden är 7 MHz. (om jag mins rätt...)

Dom TV-överföringslänkar som du hittar på kjell & co etc. jobbar på runt 2400 MHz - ungefär samma som Wlan och mikrovågsugnar då området rent allmänt anses som skräpfrekvenser med hög dämpning i luften pga. fuktigheten och störande microvågsugnar i närheten som kan inteferera.

Skall man ha _säker_ överföring så är det alltid sladd som gäller och inte luftvian - även om många glömmer bort det idag...

[Tripp]

Kolla hela videon, på slutet kommer video samplingen.

http://mydancebot.com/viewport/videos.php


/Tripp

[sysshad]

Hmm häftigt !, jag har bara lekt med basic stamp 2 än så länge, skall nog ta mig en titt på denna propeller
tack för tipset.

[Hanno]

Hi,
I apologize for posting in english- I speak german so I can follow some of your posts, but I won't attempt to write in swedish.
I'm the author of ViewPort- a tool to build advanced robots with the Parallax Propeller. In the video posted by one of your members I show how to digitize a NTSC signal with a 40Mhz ADC, read it via 8 IO pins on the Propeller, and then transfer the data to the desktop application. The Propeller has 8 cogs which run at 80Mhz, I'm using one for the measuring the ADC and compressing the image into a 24kb buffer, one for vision processing (finding the brightest spot), and 1 to stream data at 2mbps to the desktop. Please check out my site for more information: http://mydancebot.com

[maDa]

Somsagt. Okomprimerad video tar sjukt mycket bandbredd. Kolla på DVI/HDMI hur mycke dem överför bara.