Az FMUSER Wirless könnyebben továbbítja a videót és a hangot!

[e-mail védett] WhatsApp + 8618078869184
Nyelv

    IOS élő közvetítési rendszer fejlesztése (elv) 2

     

    04. Bevezetés az élő közvetítés alapismereteibe
    1. Gyűjtse össze a videót és a hangot
    * 1.1 Videó- ​​és hangkódolási keretrendszer rögzítése *
    AVFoundation: Az AVFoundation a valós idejű audiovizuális médiaadatok lejátszásának és létrehozásának kerete. Objektív-C interfészt is biztosít ezen audiovizuális adatok manipulálására, például szerkesztésre, forgatásra és újrakódolásra
    * 1.2 Video- és audioeszközök *
    CCD: Képérzékelő: Képszerzés és feldolgozás során használják a képek elektromos jelekké történő átalakítására.
    Hangfelvétel: Hangérzékelő: A hanggyűjtés és -feldolgozás során használják, a hang elektromos jelekké alakításával.
    Hangminta adatok: általában PCM formátumban
    Videomintavételi adatok: Általában YUV vagy RGB formátumban vannak. Az összegyűjtött eredeti hang és videó mennyisége nagyon nagy, és az átviteli hatékonyság javítása érdekében tömörítési technológiával kell feldolgozni
    2. Videofeldolgozás (szépség, vízjel)
    Videofeldolgozás elve: Mivel a videó képkockánként képre kerül a képernyőn a GPU-n keresztül, az OpenGL ES-t használhatjuk a videoképek feldolgozásához, így a videó különféle hatásokkal bír, akárcsak egy kifolyó csap. csöveket, majd különböző célpontok felé áramlik
    Most mindenféle szépségápolási és videofelvétel speciális effektusos alkalmazást megvalósít a GPUImage keretrendszer segítségével.
    * Videó feldolgozási keretrendszer *
    GPUImage: A GPUImage egy erőteljes kép- / videofeldolgozó keretrendszer, amely az OpenGL ES-n alapul. Különböző szűrőket foglal magában, és egyéni szűrőket is írhat. Beépített több mint 120 általános szűrőeffektussal rendelkezik.
    OpenGL: Az OpenGL (Open Graphics Library in full) egy olyan specifikáció, amely meghatározza a keresztprogramozási nyelvet, a platformokon átívelő programozási felületet, amelyet háromdimenziós képekhez használnak (kétdimenziós is lehetséges). Az OpenGL egy professzionális grafikus program interfész, egy nagy teljesítményű, könnyen hívható grafikus könyvtár.
    OpenGL ES: Az OpenGL ES (OpenGL beágyazott rendszerekhez) az OpenGL 3D grafikus API részhalmaza, amelyet beágyazott eszközökhöz, például mobiltelefonokhoz, PDA-khoz és játékkonzolokhoz terveztek.
    3. Videó kódolása és dekódolása
    * 3.1 Video kódolási keretrendszer *
    FFmpeg: egy platformon átívelő, nyílt forráskódú videorendszer, amely olyan gazdag funkciókat képes megvalósítani, mint a videó kódolása, dekódolása, átkódolása, streaming és lejátszása. A támogatott videoformátumok és a lejátszási protokollok nagyon gazdagok, beleértve szinte az összes audio és video kodeket, beágyazási formátumokat és lejátszási protokollokat.
    -Libswresample: Olyan műveleteket hajthat végre, mint az újramintavételezés, az újramátrixolás és az audio mintavételi formátumának konvertálása.
    -LibavCodec: Általános kodek keretet biztosít, amely számos video-, audio-, feliratfolyamot és más kodeket / dekódereket tartalmaz.
    -Libavformat: A videó beágyazására / lezárására szolgál.
    -Libavutil: Néhány általános funkciót tartalmaz, például véletlenszerű számgenerálást, adatszerkezetet, matematikai műveleteket stb.
    -Libpostproc: a videó néhány utólagos feldolgozásához használják.
    -Libswscale: videokép-méretezéshez, színtér-átalakításhoz stb.
    -Libavfilter: Szűrő funkció biztosítása.
    X264: Az eredeti videoadatokat YuV kódolja és tömöríti H.264 formátumba
    VideoToolbox: Az Apple saját videó-dekódoló és hardverkódoló API-ja, de csak az iOS8 után nyílt meg.
    audioToolbox: Az Apple saját audio hard dekódolása és hard coding API-ja
    * 3.2 Videokódolási technológia *
    Videotömörítési kódolási szabványok: kódolási technológiák videotömörítéshez (videokódolás) vagy dekompresszióhoz (videó dekódolás), mint például MPEG, H.264, ezek a videokódolási technológiák tömörítési kódolású videók
    Fő funkció: a video pixel adatok tömörítése video folyamba, ezáltal csökkentve a video adatok mennyiségét. Ha a videó nincs tömörítve és kódolva, akkor a hangerő általában nagyon nagy, és egy film több száz gigabájt helyet igényelhet.
    Megjegyzés: A videó minőségét leginkább befolyásolja a videó kódolási adatai és az audio kódolási adatok, amelyeknek semmi köze a csomagolási formátumhoz
    MPEG: Videotömörítési módszer, amely képkockák közötti tömörítést alkalmaz, és csak az egymást követő képkockák közötti különbségeket tárolja a nagyobb tömörítési arány elérése érdekében
    H.264 / AVC: Videotömörítési módszer, amely előzetes előrejelzést és ugyanazt a képkocka-előrejelzési módszert használja, mint az MPEG-ben a PB-keret. Az igényeknek megfelelően képes hálózati továbbításra alkalmas videofolyamot létrehozni, és nagyobb a tömörítési aránya. Jobb képminőséget
    1. megjegyzés: Ha összehasonlítja az egyetlen képernyő definícióját, az mpeg4 előnye; a cselekvés folytonosságának meghatározásából a H.264 előnye van
    2. megjegyzés: Mivel a 264 algoritmusa összetettebb, a program végrehajtása nehézkes, és futtatásához több processzor- és memóriaforrásra van szükség. Ezért a 264 futtatása viszonylag magas rendszerigényt igényel.
    3. megjegyzés: Mivel a 264 bevezetése rugalmasabb, bizonyos megvalósításokat maguk a gyártók bíznak meg. Noha ez számos előnnyel jár a megvalósításban, a különböző termékek közötti kommunikáció nagy problémává vált, aminek eredményeként az A céget átvették. A kódoló által összeállított adatokat az A vállalat dekódolójának kell megoldania az ilyen kínos dolgok megoldása érdekében.
    H.265 / HEVC: A H.264-en alapuló videotömörítési módszer, amely megtartja az eredeti technológiák egy részét, ugyanakkor javít néhány kapcsolódó technológiát a bitfolyam, a kódolási minőség, a késleltetés és az algoritmus komplexitás közötti kapcsolat javítása érdekében az optimális beállítás elérése érdekében.
    A H.265 egy hatékonyabb kódolási szabvány, amely ugyanazon képminőségi hatás mellett kisebb méretűre képes tömöríteni a tartalom mennyiségét, és gyorsabban továbbít, és spórol sávszélességet.
    I keret: (kulcskeret) teljes képet tart, csak a keret adatai szükségesek a dekódolás befejezéséhez (mert a teljes képet tartalmazza)
    P keret: (Difference frame) A kép és az előző kép közötti különbség megmarad. Dekódoláskor az előzőleg pufferelt képet rá kell helyezni az e keret által meghatározott különbségre a végső kép előállításához. (A P keret nem tartalmaz teljes képadatokat, csak az előző kép képétől eltérő adatok)
    B keret: (kétirányú különbségkeret) megőrzi az aktuális képkockák és az előző és a következő képkockák közötti különbséget. A B keret dekódolásához nemcsak az előző pufferelt képet kell megszerezni, hanem a dekódolt képet is. A végeredmény az elülső és a hátsó képek, valamint az aktuális képadatok kép egymásra helyezésével érhető el. A B keret tömörítési aránya magas, de a CPU fáradtabb lesz dekódoláskor
    Kereten belüli tömörítés: Képkeret tömörítésekor csak ennek a keretnek az adatait vesszük figyelembe, a szomszédos képkockák közötti redundáns információk figyelembevétele nélkül. Általában veszteséges tömörítési algoritmust használnak a keretben
    InteRFrame tömörítés: Időbeli tömörítés, amely tömöríti az adatokat azáltal, hogy összehasonlítja az adatokat az idő tengelyének különböző képkockái között. A képkockák közötti tömörítés általában veszteségmentes
    muxolás (szintézis): A videó-, audiofolyamokat, sőt a feliratfolyamokat is fájlba foglalja (tároló formátum (FLV, TS)) és jelként továbbítja.
    * 3.3 Hangkódolási technológia *
    AAC, mp3: Ezek hangkódolási technológiák, amelyeket tömörített hanghoz használnak
    * 3.4 Sebességszabályozás *
    Multi-bitrate: A közönség hálózati helyzete nagyon bonyolult, lehet WiFi, lehet 4G, 3G vagy akár 2G, hogyan lehet kielégíteni több fél igényeit? Készítsen még néhány sort, és testre szabhatja a bitsebességet az aktuális hálózati környezetnek megfelelően.
    Például: A videolejátszó szoftverekben gyakran látok 1024, 720, HD, SD, sima stb., Amelyek különféle bitsebességekre utalnak.
    * 3.5 Video csomagolási formátum *
    TS: Streaming média beágyazási formátum. A streaming média beágyazásának megvan az az előnye, hogy a lejátszás előtt nem kell betölteni az indexet, ami nagymértékben csökkenti az első betöltés késését. Ha a film viszonylag hosszú, az mp4 fájl indexe meglehetősen nagy, ami befolyásolja a felhasználói élményt
    Miért érdemes használni a TS-t: Ez azért van, mert két TS-klip zökkenőmentesen összekapcsolható, és a lejátszó folyamatosan játszhat
    FLV: Streaming média beágyazási formátum. A rendkívül kis fájlméret és a rendkívül gyors betöltési sebesség miatt lehetővé teszi a videofájlok megtekintését az interneten. Ezért az FLV formátum ma a mainstream videoformátum lett.
    4. Nyomja meg az Áramlást
    * 4.1 Adatátviteli keretrendszer *
    librtmp: adatok RTMP protokoll formátumban történő továbbítására szolgál
    * 4.2 Streaming média adatátviteli protokoll *
    RTMP: Valós idejű üzenetküldési protokoll, az Adobe Systems által kifejlesztett nyílt protokoll audio-, video- és adatátvitelhez a Flash-lejátszók és a szerverek között. Mivel ez egy nyílt protokoll, ezért mind használható.
    Az RTMP protokollt objektumok, videók és hangok továbbítására használják.
    Ez a protokoll a TCP protokoll vagy a lekérdezéses HTTP protokoll tetejére épül.
    Az RTMP protokoll olyan, mint az adatcsomagok tárolására szolgáló tároló. Ezek az adatok audiovizuális adatok lehetnek FLV-ben. Egyetlen kapcsolat több hálózati adatfolyamot továbbíthat különböző csatornákon keresztül, és az ezekben a csatornákban lévő csomagok rögzített méretű csomagokban kerülnek továbbításra
    darab: üzenetcsomag
    5. Streaming Media Server
    * 5.1 Gyakran használt szerverek *
    SRS: Kínai által kifejlesztett kiváló nyílt forráskódú streaming média szerver rendszer
    BMS: Ez is egy streaming média szerver rendszer, de nem nyílt forráskódú. Ez az SRS kereskedelmi verziója, és több funkcióval rendelkezik, mint az SRS
    nginx: Ingyenes és nyílt forráskódú webszerver, amelyet általában a streaming médiaszerverek konfigurálásához használnak.
    5.2 Adatmegosztás *
    CDN: A (Content Delivery Network), a tartalomszolgáltató hálózat a weboldal tartalmát a felhasználóhoz legközelebb eső hálózat "szélére" teszi közzé, hogy a felhasználó a közelben megszerezze a kívánt tartalmat, megoldja az internetes hálózat torlódásait , és javítja a felhasználó hozzáférését a weboldal reagálási sebességéhez.
    CDN: Proxy szerver, egyenértékű egy közvetítővel.
    A CDN működési elve: például streaming médiaadatok kérése
    1. Töltse fel a streaming médiaadatokat a szerverre (származási hely)
    2. A forrás állomás tárolja a streaming média adatokat
    3. Az ügyfél lejátssza a streaming médiát, és a kódolt streaming média adatokat kéri a CDN-től
    4. A CDN szerver válaszol a kérésre. Ha a streaming médiaadatok nem léteznek a csomóponton, akkor továbbra is a streaming médiaadatokat kéri a forrásállomástól; ha a videofájl már gyorsítótárazott a csomóponton, ugorjon a 6. lépésre.
    5. Az origó hely válaszol a CDN kérésre, és az adatfolyamot elosztja a megfelelő CDN csomópontnak
    6. A CDN streaming média adatokat küld az ügyfélnek
    Vissza az eredethez: Amikor a felhasználó meglátogat egy bizonyos URL-t, ha az elemzett CDN-csomópont nem tárolja a válasz tartalmát gyorsítótárba, vagy a gyorsítótár lejárt, akkor visszatér az eredeti webhelyre a keresés megszerzéséhez. Ha senki sem látogat meg, akkor a CDN-csomópont nem fog aktívan felkeresni a forráshelyet.
    Sávszélesség: A rögzített időben továbbítható összes adatmennyiség,
    Például egy 64 bites, 800 MHz-es elülső busz, adatátviteli sebessége megegyezik 64 bites × 800 MHz Hz 8 (bájt) = 6.4 GB / s
    Terheléselosztás: A szerverkészlet szimmetrikusan több szerverből áll. Minden szerver egyenértékű státusszal rendelkezik, és más szerverek segítsége nélkül önállóan is képes szolgáltatásokat nyújtani.
    Egy bizonyos terhelésmegosztási technológián keresztül a kívülről küldött kérelmek egyenletesen oszlanak el a szimmetrikus felépítésű bizonyos szervereken, és a kérést fogadó szerver függetlenül reagál az ügyfél kérésére.
    A terheléselosztás egyenletesen oszthatja el az ügyfélkérelmeket a szerver tömbben, ezáltal gyors hozzáférést biztosítva a fontos adatokhoz, és megoldva számos egyidejű hozzáférési szolgáltatás problémáját.
    Ez a klaszter technológia minimális befektetéssel képes elérni a nagygéphez közeli teljesítményt.
    QoS (sávszélesség-kezelés): Korlátozza az egyes csoportok sávszélességét, hogy a korlátozott sávszélességet maximálisan kihasználhassa
    6. Húzza az áramlást
    Élő közvetítés protokoll kiválasztása:
    Az RTMP, az RTSP azok számára használható, akiknek magas a valós idejű igénye vagy interaktív igénye van
    A lejátszásra vagy a platformokon átívelő követelményeknek azok számára a HLS ajánlott
    Élő közvetítés protokoll összehasonlítása: (5)
    HLS: Valós idejű streaming protokoll, amelyet az Apple határoz meg. A HLS a HTTP protokoll alapján valósul meg. Az átviteli tartalom két részből áll, az egyik az M3U8 leíró fájl, a másik pedig a TS média fájl. Meg tudja valósítani az élő és igény szerinti streaming médiát, főleg az iOS rendszerben
    A HLS az on-demand technológiával valósítja meg az élő közvetítést
    A HLS egy adaptív bitráta streaming. Az ügyfél automatikusan kiválasztja a különböző bitrátájú videofolyamokat a hálózati feltételeknek megfelelően. Használjon magas bitsebességet, ha a körülmények megengedik, és használjon alacsony bitsebességet, ha a hálózat foglalt, és automatikusan váltson a kettő között
    változás. Ez nagyon hasznos a zökkenőmentes lejátszás biztosításához, ha a mobil eszköz hálózati viszonyai instabilak.
    A megvalósítás módja az, hogy a szerver több bites sebességű videofolyamot biztosít, és ezt a listafájl is megjegyzi, és a lejátszó automatikusan beállítja a lejátszás előrehaladását és a letöltési sebességet.
    A HLS és az RTMP összehasonlítása: A HLS elsősorban a viszonylag nagy késésnek tudható be, és az RTMP fő előnye az alacsony késés
    A HLS protokoll kis szelet metódusa sok fájlt generál, és ezek tárolása vagy feldolgozása sok erőforrás pazarlást okoz
    Az SP protokollhoz képest az az előny, hogy a szegmentálás befejezése után az ezt követő terjesztési folyamatnak egyáltalán nem kell külön szoftvert használni. A szokásos hálózati szerver elegendő, ami jelentősen csökkenti a CDN élkiszolgáló konfigurációs követelményeit, és bármilyen kész CDN használható. , És az általános szerverek ritkán támogatják az RTSP-t.
    HTTP-FLV: Média tartalom streaming HTTP protokoll alapján.
    Az RTMP-hez képest a HTTP egyszerűbb és jól ismert, a tartalom késleltetése is lehet 1 ~ 3 másodperc, és a nyitási sebesség is gyorsabb, mert a HTTP-nek önmagában nincs komplex állapot-interakciója. Tehát a látencia szempontjából a HTTP-FLV jobb, mint az RTMP.
    RTSP: Valós idejű streaming protokoll meghatározza, hogy egy-a-sok alkalmazás miként tudja hatékonyan továbbítani a multimédiás adatokat egy IP-hálózaton keresztül.
    RTP: Valós idejű szállítási protokoll. Az RTP az UDP protokollra épül, és gyakran használják az RTCP-vel együtt. Nem nyújt időben történő kézbesítési mechanizmust vagy más szolgáltatásminőségi garanciát (QoS). E folyamat elérése érdekében alacsony szintű szolgáltatásokra támaszkodik.
    RTCP: Az RTP támogató protokollja, fő funkciója az RTP által nyújtott szolgáltatás minőségének (QoS) visszacsatolása és statisztikai információk gyűjtése a média kapcsolatról, például a továbbított bájtok száma, az továbbított csomagok száma, a elveszett csomagok száma, egy- és kétirányú hálózatok Késleltetés stb.
    7. Dekódolás
    * 7.1 Decapsulation *
    Demuxing (elválasztás): Bontsa le a videót, a hangot vagy a feliratokat a fájlból (tároló formátum (FLV, TS)), amelyet a videofolyamból, az audió folyamból és a feliratfolyamból szintetizál, és külön dekódolja őket.
    * 7.2 Hangkódolási keretrendszer *
    fdk_aac: Hangkódoló és dekódoló keretrendszer, PCM audio adatok és AAC audio adatok átalakítása
    * 7.3 Dekódolás bevezetése *
    Kemény dekódolás: A GPU segítségével dekódolhat, csökkentheti a CPU műveleteit
    Előnyök: sima lejátszás, alacsony energiafogyasztás, gyors dekódolási sebesség,
    * Hátrányok: gyenge kompatibilitás
    Lágy dekódolás: A dekódoláshoz használja a CPU-t
    Előnyök: jó kompatibilitás
    * Hátrányok: megnövekedett CPU-terhelés, megnövekedett energiafogyasztás, nincs hardver

    Sima dekódolás, viszonylag lassú dekódolási sebesség
    8. Játék
    ijkplayer: nyílt forráskódú Android / iOS videolejátszó, amely az FFmpeg alapú
    Az API könnyen integrálható;
    A fordítási konfiguráció levágható a telepítési csomag méretének szabályozásának megkönnyítése érdekében;
    Támogatja a hardveres gyorsítás dekódolását, több energiamegtakarítást
    Egyszerű és könnyen használható, adja meg a streaming URL-t, automatikusan dekódolja és játssza le.
    9. Csevegési interakció
    IM: (InstantMessaging) Azonnali üzenetküldés: egy valós idejű kommunikációs rendszer, amely két vagy több ember számára lehetővé teszi a hálózat használatát valós idejű szöveges üzenetek, fájlok, hang és videó kommunikációjához.
    Az IM fő szerepe az élő közvetítési rendszerben a közönség és a horgony, valamint a közönség és a közönség közötti szöveges interakció megvalósítása.
    * Harmadik fél SDK *
    Tencent Cloud: A Tencent által biztosított azonnali üzenetküldés SDK, amely élő csevegőszobaként használható
    Rongyun: Gyakran használt azonnali üzenetküldő SDK, amely élő csevegőszobaként használható
    5. Hogyan lehet gyorsan kifejleszteni egy teljes iOS élő streaming alkalmazást
    1. Használjon harmadik féltől származó élő streaming SDK-t a gyors fejlődéshez
    Qiniu Cloud: A Qiniu Live Cloud egy globális élő streaming szolgáltatás, amelyet kifejezetten élő streaming platformok számára hoztak létre, és egy vállalati szintű élő streaming felhő szolgáltatási platform, amely SDK end-to-end élő streaming forgatókönyveket valósít meg.
    * Az élő streaming platformok, például a Panda TV és a Dragon Ball TV, mind a Qiniu Cloud-ot használják
    NetEase Video Cloud: A professzionális, több platformos videokodek technológián és a nagyméretű videotartalom-terjesztési hálózaton alapulva stabil, sima, alacsony késleltetésű, nagy párhuzamosságú, valós idejű audio- és video szolgáltatásokat nyújt, és zökkenőmentesen összekötheti az élő videókat saját App.
    2. Miért nyújtanak harmadik féltől származó SDK-vállalatok SDK-kat nekünk?
    Reméljük, hogy termékünket és azt ugyanarra a hajóra tudjuk kötni, és jobban bízunk benne.
    A technológia pénzt keres és segít nagyszámú programozó felnevelésében
    3. Élő közvetítés funkció: önkutatás vagy harmadik féltől származó élő közvetítés SDK fejlesztése?
    Harmadik féltől származó SDK fejlesztés: Egy induló csapat számára a saját fejlesztésű élő közvetítésnek nagy a küszöbértéke a technikai küszöb, a CDN és a sávszélesség szempontjából, és egy kész termék elkészítése sok időt vesz igénybe, ami nem kedvez befektetéshez.
    Önkutatás: A társaság élő közvetítési platformja nagy. Hosszú távon az önkutatás költségeket takaríthat meg, és a technikai szempontok sokkal jobban ellenőrizhetők, mint közvetlenül az SDK használata.
    4. Harmadik fél SDK előnyei
    csökkentse a költségeket
    Használjon jó, harmadik féltől származó vállalati szolgáltatásokat, így már nem kell magas árakat költenie, hogy fejvadászokat alkalmazzon drága nagy tehenek ásásához, és nincs szükség a nagy tehenek személyes temperamentumának megnyugtatására.
    Hatékonyság fejlesztése
    A harmadik féltől származó szolgáltatások és a kódintegráció által nyújtott kényelem csak 1-2 órát vehet igénybe, ami az idő közel 99% -át megtakarítja, ami elegendő cserébe több időre a versenytársak elleni harcra és a növekedésre. Nagy a siker lehetősége
    csökkenti a kockázatot
    A professzionális, harmadik féltől származó szolgáltatások segítségével gyors, professzionális, stabil és egyéb jellemzői miatt nagymértékben javíthatja a termékek versenyképességét (magas színvonalú szolgáltatások, a kutatás és fejlesztés sebessége stb.), És lerövidítheti a tárgyalást és a hibaidő, amely minden bizonnyal az élet egyik megmentésének eszköze lesz a vállalkozói szellemben.

     

     

     

     

     

     

    Milyen messze (hosszú) a távadó fedelét?

    A hatótávolság számos tényezőtől függ. Az igazi távolságot alapul az antenna telepítéséhez magasság, antennanyereség használva környezetben, mint épület és egyéb akadály, érzékenysége a vevő, antenna a vevő. Telepítése antenna több magas és használata vidéken, a távolság sokkal messzebb.

    Példa 5W FM Transmitter használja a városban és a szülővárosa:

    Van egy magyar ügyfél használja 5W fm transmitter GP antenna szülővárosában, s kipróbálni egy autót, akkor terjed 10km (6.21mile).

    Tesztelem a 5W fm transmitter GP antenna szülővárosomban, ez fedezésére mintegy 2km (1.24mile).

    Tesztelem a 5W fm transmitter GP antenna Guangzhou város, akkor terjed csak körülbelül 300meter (984ft).

    Az alábbiakban a hozzávetőleges sor különböző teljesítmény FM adó. (A tartomány átmérő)

    0.1W ~ 5W FM adó: 100M ~ 1KM

    5W ~ 15W FM Ttransmitter: 1KM ~ 3KM

    15W ~ 80W FM adó: 3KM ~ 10KM

    80W ~ 500W FM adó: 10KM ~ 30KM

    500W ~ 1000W FM adó: 30KM ~ 50KM

    1KW ~ 2KW FM adó: 50KM ~ 100KM

    2KW ~ 5KW FM adó: 100KM ~ 150KM

    5KW ~ 10KW FM adó: 150KM ~ 200KM

    Hogyan léphet kapcsolatba velünk az adó?

    Hívjon + 8618078869184 OR
    Küldj e-mailt [e-mail védett]
    1.How messze szeretné fedezni átmérőjű?
    2.How magas közületek torony?
    3.Where vagy?
    És akkor kapsz több szakmai tanácsot.

    Rólunk

    Az FMUSER.ORG egy olyan rendszerintegrációs cég, amely az RF vezeték nélküli átvitelre / stúdió-videó hangberendezésre / streamingre és adatfeldolgozásra összpontosít.
     
    FM adó, analóg TV adó, digitális TV adó, VHF UHF adó, antennák, koaxiális kábelcsatlakozók, STL, levegő feldolgozás, műsorszórási termékek a stúdióhoz, RF jel felügyelet, RDS kódolók, audio processzorok és távoli webhelyvezérlő egységek, IPTV termékek, Video / Audio Encoder / Decoder, úgy tervezték, hogy megfeleljenek mind a nagy nemzetközi műsorszóró hálózatok, mind a kis magánállomások igényeinek.
     
    Megoldásunk FM rádióállomás / analóg tévéállomás / digitális tévéállomás / audio-video stúdió berendezés / stúdió adó-összeköttetés / adó-telemetria rendszer / szálloda TV-rendszer / IPTV élő közvetítés / élő közvetítés / videokonferencia / CATV műsorszóró rendszer.
     
    Az összes rendszerhez fejlett technológiai termékeket használunk, mert tudjuk, hogy a nagy megbízhatóság és a nagy teljesítmény olyan fontos a rendszer és a megoldás szempontjából. Ugyanakkor meg kell győződnünk arról, hogy termékrendszerünk nagyon kedvező áron van.
     
    A közszolgálati és kereskedelmi műsorszolgáltatók, a távközlési szolgáltatók és a szabályozó hatóságok ügyfelei vannak, és megoldásokat és termékeket is kínálunk több száz kisebb, helyi és közösségi műsorszolgáltatónak.
     
    Az FMUSER.ORG több mint 15 éve exportál, és ügyfelei vannak a világ minden tájáról. 13 éves tapasztalattal rendelkezik ezen a területen, van egy profi csapatunk, hogy megoldjuk az ügyfelek mindenféle problémáját. Elkötelezettek vagyunk a professzionális termékek és szolgáltatások rendkívül elfogadható árainak biztosításában.
    Kapcsolattartó e-mail : [e-mail védett]

    a Factory

    Nekünk van korszerűsítés a gyár. Szeretettel várjuk, hogy látogassa meg a gyár, ha jön Kínába.

    Jelenleg már vannak 1095 ügyfelek világszerte látogatott el Guangzhou Tianhe irodában. Ha jön Kína, szívesen látogasson el hozzánk.

    Fair

    Ez a mi részvétel 2012 Global Sources Hong Kong Electronics Fair . Az ügyfelek a világ minden tájáról végre van egy esélyt, hogy együtt legyünk.

    Hol van Fmuser?

    Kereshet ezekben a számokban " 23.127460034623816,113.33224654197693 "a google térképen, akkor megtalálhatja fmuser irodánkat.

    FMUSER Guangzhou irodája Tianhe District, amely a központja a Canton . Nagyon közel hoz Canton Fair , Guangzhou vasútállomás, Xiaobei közúti és dashatou , Csak be kell 10 perc ha figyelembe TAXI . Üdvözöljük barátok a világ minden tájáról, hogy látogassa meg, és tárgyaljon.

    Kapcsolat: Sky Blue
    Mobil: + 8618078869184
    WhatsApp: + 8618078869184
    Wechat: + 8618078869184
    Email: [e-mail védett]
    QQ: 727926717
    Skype: sky198710021
    Cím: No.305 szoba Huilan Building No.273 Huanpu Road Guangzhou Kína Zip: 510620

    Angol: Minden fizetést elfogadunk, például PayPal, Hitelkártya, Western Union, Alipay, Money Bookers, T / T, LC, DP, DA, OA, Payoneer. Ha bármilyen kérdése van, kérjük, vegye fel velem a kapcsolatot [e-mail védett] vagy a WhatsApp + 8618078869184

    • PayPal.  www.paypal.com

      Azt javasoljuk, hogy a Paypal vásárolni a terméket, a Paypal biztonságos módon vásárolni az interneten.

      Minden a mi elem lista oldal alján tetején van egy paypal logóra fizetni.

      Hitelkártya.Ha nincs paypal, de van, hitelkártya, akkor is kattints a sárga gombra PayPal fizetni a hitelkártya.

      -------------------------------------------------- -------------------

      De ha nem egy hitelkártya, és nem egy paypal számla, vagy nehezen kapott egy paypal fiókot állíthat, használhatja a következő:

      Western Union.  www.westernunion.com

       

      Fizessen Western Union nekem:

      Keresztnév / Keresztnév: Yingfeng
      Vezetéknév / Vezetéknév / Családnév: Zhang
      Teljes név: Yingfeng Zhang
      Ország: Kína
      Város: Guangzhou 

      -------------------------------------------------- -------------------

      T / T.  Fizessen T / T (átutalás / banki átutalás / banki átutalás)
       
      Első BANKINFORMÁCIÓ (VÁLLALATI SZÁMLA):
      SWIFT BIC: BKCHHKHHXXX
      Bank neve: BANK OF CHINA (HONG KONG) LIMITED, HONGKONG
      Bank címe: BANK OF CHINA TOWER, 1 GARDEN ÚT, CENTRAL, HONG KONG
      BANKKÓD: 012
      Számla neve: FMUSER INTERNATIONAL GROUP LIMITED
      Számlaszám. : 012-676-2-007855-0
      -------------------------------------------------- -------------------
      Második BANK-INFORMÁCIÓ (VÁLLALATI SZÁMLA):
      Kedvezményezett: Fmuser International Group Inc.
      Fiókszám: 44050158090900000337
      Kedvezményezett bankja: China Construction Bank Guangdong Branch
      SWIFT kód: PCBCCNBJGDX
      Cím: NO.553 Tianhe Road, Guangzhou, Guangdong, Tianhe District, Kína
      ** Megjegyzés: Ha pénzt utal át bankszámlánkra, kérjük, NE írjon semmit a megjegyzés területére, különben a nemzetközi kereskedelemre vonatkozó kormányzati politika miatt nem tudjuk megkapni a befizetést.

    * Ez lesz elküldve 1-2 munkanap, amikor a fizetési világos.

    * Mi elküldjük azt a paypal címét. Ha meg akarjuk változtatni a címet, kérjük, küldje el a megfelelő címet és telefonszámot az email [e-mail védett]

    * Ha a csomagok alatt 2kg fogjuk szállítani postai légiposta, akkor körülbelül 15-25days a kezedbe.

    Ha ez a csomag több, mint 2kg, akkor a hajó keresztül EMS, DHL, UPS, Fedex gyors expressz szállítás, akkor körülbelül 7 ~ 15days a kezedbe.

    Ha a csomag több, mint 100kg küldünk keresztül DHL vagy a légi áruszállítás. Ez körülbelül 3 ~ 7days a kezedbe.

    Minden csomag formájában Kína Guangzhou.

    * A csomagot "ajándékként" küldjük el, és a lehető legkevesebbet nyilatkozunk, a vevőnek nem kell fizetnie az "adóért".

    * Miután a hajó, küldünk Önnek egy e-mailt, és adja meg a nyomon követési számot.

    A jótállásért.
    Lépjen kapcsolatba velünk --- >> Tegye vissza nekünk a terméket --- >> Fogadás és újabb csere küldése.

    Név: Liu Xiaoxia
    Cím: 305Fang HuiLanGe HuangPuDaDaoXi 273Hao TianHeQu Guangzhou Kína.
    Postai irányítószám: 510620
    Telefon: + 8618078869184

    Kérjük, térjen vissza erre a címre, és írja meg a paypal címét, nevét, probléma megjegyzés:

    Sorold fel az összes kérdés

    Becenév

    E-mail

    Kérdések

      Írja be az e-mail címet a meglepetéshez

      fmuser.org

      es.fmuser.org
      it.fmuser.org
      fr.fmuser.org
      de.fmuser.org
      af.fmuser.org -> afrikaans
      sq.fmuser.org -> albán
      ar.fmuser.org -> arab
      hy.fmuser.org -> örmény
      az.fmuser.org -> azerbajdzsán
      eu.fmuser.org -> baszk
      be.fmuser.org -> belorusz
      bg.fmuser.org -> bolgár
      ca.fmuser.org -> katalán
      zh-CN.fmuser.org -> kínai (egyszerűsített)
      zh-TW.fmuser.org -> kínai (hagyományos)
      hr.fmuser.org -> horvát
      cs.fmuser.org -> cseh
      da.fmuser.org -> dán
      nl.fmuser.org -> holland
      et.fmuser.org -> észt
      tl.fmuser.org -> filippínó
      fi.fmuser.org -> finn
      fr.fmuser.org -> francia
      gl.fmuser.org -> galíciai
      ka.fmuser.org -> grúz
      de.fmuser.org -> német
      el.fmuser.org -> Görög
      ht.fmuser.org -> haiti kreol
      iw.fmuser.org -> héber
      hi.fmuser.org -> hindi
      hu.fmuser.org -> magyar
      is.fmuser.org -> izlandi
      id.fmuser.org -> indonéz
      ga.fmuser.org -> ír
      it.fmuser.org -> olasz
      ja.fmuser.org -> japán
      ko.fmuser.org -> koreai
      lv.fmuser.org -> lett
      lt.fmuser.org -> litván
      mk.fmuser.org -> macedón
      ms.fmuser.org -> maláj
      mt.fmuser.org -> máltai
      no.fmuser.org -> norvég
      fa.fmuser.org -> perzsa
      pl.fmuser.org -> lengyel
      pt.fmuser.org -> portugál
      ro.fmuser.org -> román
      ru.fmuser.org -> orosz
      sr.fmuser.org -> szerb
      sk.fmuser.org -> szlovák
      sl.fmuser.org -> Szlovén
      es.fmuser.org -> spanyol
      sw.fmuser.org -> szuahéli
      sv.fmuser.org -> svéd
      th.fmuser.org -> Thai
      tr.fmuser.org -> török
      uk.fmuser.org -> ukrán
      ur.fmuser.org -> urdu
      vi.fmuser.org -> Vietnámi
      cy.fmuser.org -> walesi
      yi.fmuser.org -> jiddis

       
  •  

    Az FMUSER Wirless könnyebben továbbítja a videót és a hangot!

  • Kapcsolat

    Cím:
    No. 305 szoba HuiLan épület No.273 Huanpu Road Guangzhou, Kína 510620

    Email:
    [e-mail védett]

    Tel / WhatApps:
    +8618078869184

  • Kategóriák

  • Hírlevél

    ELSŐ VAGY TELJES NÉV

    E-mail

  • paypal megoldás  Western UnionKínai bank
    Email:[e-mail védett]   WhatsApp: +8618078869184 Skype: sky198710021 Beszélgess velem
    Szerzői 2006-2020 Powered By www.fmuser.org

    Kapcsolatba lép velünk