Nu har dotterns farmor&farfar oxå skaffat bredband i syfte att bl a kunna prata med och se henne via någon form av Webcam (är tyvärr 45 mil mellan oss), och då måste ju man skaffa sig webcam´s.
Är helt novis på detta med dessa webcams och har ingen aning om vad man ska ha och vilka funktioner som bör ingå?

Lite krav/önskemål :

-Färgbild
-Inte så hackig bild, och god bildkvalité
-Ej så dyr
-Enkel att installera
-Man ska kunna prata med varandra
-?


PC spec är bl a: 3,4GHz, 1Gb RAM, X800XT 256Mb PCI Express, USB2.0, Firewire 1394 (?), XP Home med SP2 och BBB som ISP.

Tacksam för all och snabb hjälp eftersom detta ska införskaffas senast under helgen.

Logitech Quickcam Zoom tycker jag verkar vara en kamera som skulle kunna passa, du kan ju läsa lite om den här

Logitech

Äger en Logitech kamera själv sedan en längre tid... måste säga att den funkar över förväntan, Den modellen jag har (utgått ur sortimentet) har även inbyggd mic så någon extern behövs inte.

Har för mej att den heter Express 3000 pro typ...så den kan nog liknas den nya 4000 serien fast jag antar att 4000 har bättre upplösning än vad min har.

Jag har för mej att jag gav runt 4-500kr för den ny.

/JBP

Varför tycker du den är lämplig för mina ändamål, m a o vad i specifikationen är det som gör den bra?

Skillnaderna mellan Quickcam Pro 4000 och Ouickcam Zoom är ju att du har möjlighet till en högre upplösning vid stillbildsfotografering, bägge har ju inbyggd mikrofon, så prata med varandra skall ju fungera med bägge, såg nu att prisskilnaden inte var så stor mellan de två olika kamerorna så det kanske är läge att titta på Pro 4000 också bägge har ju annars 30 frames/s vid videokonversation, så där borde ju inte vara nån skillnad. (Har själv en ännu äldre variant av Quickcam Pro, snart fem år gammal, är klart nöjd med den, har aldrig dummat sig.)

Och det är bra "flyt i bilden" ?

det beror ju väldigt mycket på hur pass bra bandbredd du och "mottagaren" har vid tillfället... men givetvis finns det ju alltid en lite fördröjning på både ljud och bild tyvärr och det är inget man kommer ifrån..

Sen efter jag har kollat runt lite på logitechs hemsida så skulle jag rekomendera dej 4000 Pro framför Zoom, mest på grund av att den har bättre upplösning i stillbild (troligen i video också) samt att även denna har zoommöjligheter.

/JBP

Ja, 30 bilder/s är bra, sedan ska man ju komma ihåg att oavsett hur snabb kamera/dator du har så är ju bandbredden ut på nätet av stor betydelse också du kan ju ha hur snabba grejor som helst men har du dålig fart i bredbandet så blir det ju en flaskhals där ändå.

Har Spheremodellen, fungerar bra. Hyfsad i dåligt ljus, mycket bättre i bra ljus. Ansiktsföljningsfunktionen fungerar bra när man vill ha det så, går att stänga av. Kan användas med förlängningspinnen eller utan, bra idé tycker jag, de som har tunna skärmar kan ju inte ställa kameran ovanpå skärmen, perfekt höjd för mig i alla fall med den här kameran. Använder inte mikrofonen som byggts in utan har den här: Mikrofon

http://www.apple.com/isight/ mmmmm....

mmm...nice.. Var kan man köpa den?

Hos apple, i deras egen webbshop

Logitech anser jag har dom .Andvänder Kameran dagligen vid Chat med familj och affärsbekanta..Andvänder både Skype och msn.Det jag gillar är priset och att dom har bra support.Har haft andra men dom har strulat vid uppdateringer och sånt..


MVH
Olaevil

Själva bandbredden är oftast av underordnad betydelse för videokonferenssystem, vilket det här räknas som, utan det är dataförlust och latency (datatrafikens fördröjning) som spelar största rollerna i praktiken. Här är några siffror:

Dataförlust (främst då vid användande av UDP över IP):

1% klart synbara bildstörningar
2% oanvändbart

Envägs latency (i en dubbelriktad videokonferens):

< 30 ms önskvärt
< 100 ms acceptabelt
> 100 ms problematiskt
> 300 ms oanvändbart

International Telecommunication (ITU) rekommenderar i;

ITU-T Recommendation G.114 - Transmission Systems and
Media. General Characteristics of International Telephone
Connections and International Telephone Circuits, 1996

att envägslatency för ett videokonferenssystem inte bör överstiga 150 ms för att ge acceptabel prestanda. Jag har inte själv testat videokonferenssystem i praktiken, men 100 ms låter som rätt så kort tid för att fånga och komprimera bild och ljud, föra över det över Internet samt slutligen dekomprimera bild och ljud samt spela upp dem.

Det kan vara värt att notera att en IPTV-sändning i normal upplösning (SDTV) tar upp cirka 7 Mbps och börjar ge riktigt kass bild vid mindre än 1% dataförlust.

Fungerar för övrigt iSight med Windows/PC?

Tycker dessa siffror verkar lite extrema, för vilken videokodning gäller de?

Nu vet jag inte vilka metoder dessa program använder för att föra över bild och ljud mellan användarna, men det finns komprimeringsalgoritmer som är konstruerade för att tåla förluster av paket, utan att användarna skall märka så mycket

Ska erkänna att jag inte har en aning om det, kände bara att jag var tvungen att göra ett meningslöst inlägg/puffa för ännu en utmärkt produkt från Cupertino Välj själv det alternativ som passar bäst

Fan Säga att det 100% live på bilderna men bra nära ändå.Men inom Sverige med Bredband borde det inte va något problem att få det att flyta...Sen få man ju se det som det är sitter man och tankar samtidigt så hackar det ju men annars då rör sig bilderna rätt bra även över Atlanten.....

MVH
Olaevil

Jag vill minnas att siffrorna var för någon av H.261 eller H.263 standarderna, men kommer tyvärr inte ihåg detaljerna. Det räcker för övrigt med betydligt mindre än 0,1% dataförlust i en MPEG/UDP/IP-baserad IPTV-ström för att det ska bli så stora störningar att det är oacceptabelt för hemanvändare. Med cirka 1% procent dataförlust, så blir sedan bilden så dålig att det blir svårt att se vad den föreställer. Förutom att läsa forskningsrapporter inom området som nämner detta, så har jag även själv gjort de mätningarna och sett resultaten i praktiken. Tänk här på att den spatiala och temporala kodningen i MPEG gör att fel fortplantar sig rejält.



Vilka komprimeringsalgoritmer stödjer det för audio och video? Jag påstår inte att de inte finns, utan jag är nyfiken på vilka de är. Hur stora dataförluster tål de innan kvalitén blir rejält dålig? Du får dessutom svårt att komma ifrån latencyproblemen i videokonferenssystem, oavsett vilka komprimeringsalgoritmer du använder, då du även har datorns hårdvarulatency och nätverkets latency.

Som nöjd PowerBook-användare, så tycker jag att du gjorde helt rätt i det.

Om du säger så är det säkert sant.

Jag har inte så mycket erfarenhet av videokodning, mest av audio och då mest mulicast och inte ptp, men överlag är inte mycket heller

Jag har letat men hittar inte arbetet som jag gjorde om det så jag kommer inte ihåg protokollnamnen (ska fortsätta att leta) men jag tänker på tekniker som forward error correction, piggyback riding och interleaving

Skillt från standarderna så kan man kanske använda tekniker som sliding window eller något liknande för att motverka problem då man tappar många packet efter varandra.

Jag tycker mig minnas att man med dessa tekniker kunde bibehålla en godtagbar audiokvalite med en så hög packetlost som 20%, tyvärr har jag inget att backa upp det med :(

Nu är ju inte dessa komprimeringsalgoritmer. FEC ökar skyddet mot störning genom att lägga till redundans i datan, vilket till skillnad från en komprimeringsalgoritm ökar storleken på datan. FEC ökar även latencyn. Vad avser du med piggyback riding i det här sammanhanget? Interleaving tillför primärt skydd mot salvdistribuerade (burstiga) fel och ökar även latencyn. Om man använder radio som sitt fysiska lager, så kan man även använda Direct Sequence Spread Spectrum (DSSS) och Frequency Hopping Spread Spectrum (FHSS) för att öka skyddet mot störningar på en viss frekvens. Man kan för övrigt använda FEC på praktiskt smarta sätt när det gäller skydd av videodata, som exempelvis MPEG, då all data inte behöver skyddas lika mycket. Man lägger då på en fetare FEC på headers än på resten av datan, och kan även lägga en olika fet FEC på olika delar av headern beroende på hur viktig den är. På det sätt minskar man risken för katastrofala bildstörningar, samtidigt som man inte ökar den totala datastorleken alltför mycket.



Ett enkelt sätt att i praktiken undvika dataförluster är att använda TCP istället för UDP, då det första protokollet, till skillnad från den andra, har inbyggt stöd för omsändningar på transportprotokollnivå. Problemet är att man då p.g.a. ökad latency lätt förlorar sin realtidsprestanda. Det är just sådana saker som gör realtidsmultimedia, som exempelvis de aktuella videokonferenserna, så svårt. Ett annat praktiskt problem är att man med UDP har felgranularitet på datagramnivå och med TCP på segmentnivå. Detta innebär att om det bli en enda bit fel i ett datagram eller segment, så kommer hela datagrammet eller segmentet, som vanligtvis innehåller många tusentals bitar data, att kastas bort efter checksummekollen.

Nej, tyvärr gör den inte det. Men man kan ju hoppas att Apple gör den PC-kompatibel en vacker dag.

Ok, jag hade fått för mig att det fanns videokodningsalgoritmer som innehöll dessa tekniker, fast de kanske utelsutande ingår i överförningsalgoritmerna.



Att man tillför en nedskalad version av ett pakets datat på paketet som kommer efter.




Är det ens möjligt att få realtidsprestanda över TCP någon annanstans än i en kontrollerad miljö? Ett annat stort problem är också att UDP helt saknar tekniker för att ta hänsyn till annan trafik än den egna. Hitils har man ju löst det med att bara bygga snabbare nätverk, men det ska bli roligt och se om det kommer någon bättre lösning snart.

Så kontentan av detta tekniska m umbo-jumbo är att jag ska åka till Elgiganten och shoppa en Logitech med 30 bilders/s?!

@NisseNord & A2Keltainen
Vilka flashbacks jag får av er diskussion! Våren 2000 höll jag på med precis det här när jag gick telecom-inriktningen i Kista. Mitt projekt var att skriva programvara för att överföra en digital videoström (rå DV-data från en videokamera) över nätet för att sedan spela upp/in den på en annan DV-kamera. En teknik som heter Real time Transfer Protocol (RTP, RFC3267) visade sig vara väldigt lämplig för just det. Den bygger på vanlig UDP men innehåller även mycket noggranna tidsstämplar, "bäst före"-tid, kanaler med olika prioritet osv.

Jag har snöat in mig en del på RTP och liknande saker i mitt arbete på sistone. Det är trevligt att få betalt för att läsa forskningsrapporter och andra roliga tekniska saker.

Ledsen om vi sabbade din tråd lite men för att ankynta till ditt problem så kan jag säga att stirra dig inte bara blind på hårdvaran, vilken mjukvara man använder är minst lika viktig. Nu har jag inga egna erfarenheter inom detta område, men det finns säkert andra som har det.