Új hozzászólás Aktív témák

• #15987 janos666 nagyúr Mr Dini #15983

  Új Válasz 2015-12-01 18:40:17 #15987

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  janos666

  nagyúr

  válasz Mr Dini #15983 üzenetére

  Nem a kártyára akarok (akartam) írni, hanem ffmpeg-el RTSP stream-et olvasni (ott helyben inkább UDP, de talán már ott is TCP csomagokat, ami beválik), muxolni TS videó konténer formátumba (X86 CPU-n ez elenyésző terhelés) és azt kiírni egy Raspberry-n mount-olt Samba share-be (a távoli szerverre).
  Szóval ami korlát lehet, az vagy az ethernet rész gyakorlati átengedő képessége, vagy inkább a CPU nyers ereje (párosítva az adott Linux kernel SMB kódjának optimalizáltságával), így átalakítva a forgalom jellegét, amit WiFi-n kell átküldeni, ami így némi RAM bufferrel is meg lenne támogatva (ha pl. marad 64Mb szabad RAM, az is elég lehet arra az esetre, ha egy pillanatra meglassul a WiFi valami átmeneti interferenciától).

  Az egész WiFi téma azért van, hogy az adatok minimális késéssel (pár másodperc) egy központi, távoli helyen legyenek, nem helyben szeretném őket menteni.

• #15980 janos666 nagyúr Mr Dini #15974

  Új Válasz 2015-12-01 15:21:16 #15980

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  janos666

  nagyúr

  válasz Mr Dini #15974 üzenetére

  Kösz. Ezek szerint akkor karcsú lenne erre.

• #15971 janos666 nagyúr RoundRobin #15970

  Új Válasz 2015-11-30 17:11:41 #15971

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  janos666

  nagyúr

  válasz RoundRobin #15970 üzenetére

  Ha megnézed a screenshot-om, az egyértelművé tesz pár dolgot, ami viszonylag érdektelenné teszi a hozzászólásod: például hogy
  1: N-es rádió (szóval kit érdekel, hogy mit tud a B és G? most komolyan? )
  2: itt nálam vidéken kellemesen alacsony a noise floor
  3: mekkora az elméleti, illetve a szintetikusan generált és ténylegesen lebonyolított adatforgalom konkrét mérése

  Legközelebb másolj be egy másik bekezdést a wikipedia hasábjairól, hátha...
  De ha lehet, inkább majd egy Raspberry Pi témába vágót másolj át, mert mégis csak Raspberry Pi topic lenne ez...

  Én közben három napi folyamatos bénázás és végül már szenvedés eredményeképp végre tényleg megtaláltam a megoldást. [link]

  Esetleg amiatt érhetné meg mégis tenni oda Raspberry-ket, mert az ffmpeg-hez nem találok semmilyen bufferelési opciót, Samba-val viszont nagyon egyszerű lenne elérni azt, hogy szép nagy szeleteken írjon a tárhelyre, így ne legyen apróra töredezve minden *.ts file. Ez nem kritikus, de nem túl drágák ezek a kütyük, főleg ha elég lenne erre a célra a legkisebb és legrégibb RJ45-el is szerelt kivitel, ami már tényleg olcsó használtan.

  Szóval mégis érdekel még, hogy mégis mit tudnak ezek SMB share-re írásban.

• #15969 janos666 nagyúr azbest #15968

  Új Válasz 2015-11-30 12:17:13 #15969

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  janos666

  nagyúr

  válasz azbest #15968 üzenetére

  Összesen 4db SXT-L5 van, amiknek páronként 4-4 kamerával kéne elbánniuk.
  Kb. ez áll rendelkezésre: kétirányba egyszerre 65/65 Mbps 4 TCP kapcsolattal, tehát kvázi van egy Duplex 100Mbps link-em a levegőben (nagyjából pont ezt tudom mérni így TCP-vel egy ethernet switch-en keresztül is <=10m CAT5e kábelekkel, UDP-vel 95+ oda-vissza, de azzal a WiFi valamivel 100 felett fut be...).

  A kamerák maximum 8Mbps videót tolnak, de átlagban kevesebbet, inkább valahol 3-5 közt, tehát overhead-el együtt is bele kéne férnie 10Mbps-be.

  Ha elindítom a rögzítést (ffmpeg "copy" codec-el és *.ts kimenet), akkor nagyjából annyi az adatforgalom az SXT-k közt, amit várok, ha pedig ráindítok mellette valami szintetikusan generált tesztforgalmat, akkor határozottan magasabbra ugrik, miközben az ffmpeg szerint nem esik le a rögzített bitráta.

  De valamiért mégis hibásak a videók. Pedig kipróbáltam itthon a kamerákat, mielőtt felszereltem őket, illetve most is van itthon egy ugyan ilyen kamera, közvetlenül kábellel ugyan azon az 1000Mbps switch-en, amibe az SXT-k is bekötnek ezen az oldalon és azt vígan lehet rögzíteni hibák nélkül. A többi 8, ami távol van, az viszont mind szarakodik.

  Akkor is szar a rögzített videó, ha semmi más nem csatlakozik egy adott kamerához, csak az ffmpeg. De a végig kábelen lógó kamerát nyugodtan lehet közben nézegetni mobiltelefonon is, nem kottyan meg neki (tesztképp már próbáltam egyszerre több ffmpeg folyamattal is rögzíteni a nagyfelbontású videót külön file-okba és 4 kapcsolatig jutottam, mielőtt megtagadta az ötödiket).

  Valami olyasmit sejtek, hogy apró kis csomagokat szeret küldeni a kamera, amit nem szeret a WiFi (se a 802.11, se az NV2 mód - bár utóbbi nem is P2P bridge-hez lett kitalálva, és pl. a TCP-t külön nem szereti...; az nstreme módban pedig folyton disconect-el, így még nem is tudtam kitalálni, hogy az mire lehet jó vagy nem jó, ez gondlom már csak "legacy" támogatású)., valahogy épp eléggé lelassul a dolog ahhoz, hogy elkezdje valahol valami eldobálni a csomagokat és/vagy komplett timeout-ot okozni.
  De nem jöttem még rá, pedig 2 napja kínlódok a beállításokkal és a google-el. Elkeseredésemben jön ez a B terv, hogy "aktív okos eszközt" tegyek a távoli helyekre, fogják meg azok a strem-et és küldjék vissza komótosabban bufferelve, nagy csomagokban SMB-n.

• #15965 janos666 nagyúr footy #15963

  Új Válasz 2015-11-30 09:35:26 #15965

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  janos666

  nagyúr

  válasz footy #15963 üzenetére

  Melyik kivitelre lenne szükségem, illetve elég-e egyáltalán bármelyik, ha durván 32Mbps (4MB/s) sebességgel szeretnék írni (tartósan, stabilan) egy Raspberry-n mount-olt Samba (kényszerből esetleg NFS) hálózati mappába, ahol a bemenet szintén a hálózatról jön (de csak minimális módosítással megy tovább)?

  Ahogy keresgéltem, inkább a másik irányba láttam méréseket és általában az volt a konklúzió, hogy file-ok mozgatásakor sokat számít a Raspberry-n használt filerendszer is, ami itt irreleváns lenne, lényegében hálózatról hálózatra másolnék. Kicsit konkrétabban RTSP-n H264 videó stream-et fogadna és újrakódolás nélkül pakolná bele *.ts file-ba, mert ez valamiért nem akaródzik működni wireless bridge-en keresztül, hiába lenne meg a szintetikus mérések szerint a szükséges sávszélesség többszöröse is és mindhiába játszogatok már a beállításokkal napok óta.

Új hozzászólás Aktív témák