Absztrakt: A vezetékes és vezeték nélküli hálózatok szélessávának gyors fejlődésével az emberek már nem elégedettek az egyszerű információkkal, például az internetes szavakkal és képekkel, de egyre többen szeretnének intuitívabb és gazdagabb film- és televíziós programokat látni. Ezért megjelennek a streaming média webhelyek. Ez a cikk a streaming média weboldal fejlesztését fejti ki a streaming média koncepció, a streaming média formátum, a streaming média fájlok előállítása, a streaming média fájlok továbbítása, a streaming média fájlok közzététele és a streaming média webhelyek telepítése szempontjából.
Kulcsszavak: streaming média weboldal fejlesztése és telepítése
1. Áttekintés
Kétféle módon lehet multimédiás üzeneteket továbbítani a hálózaton: letölthető és streaming. Ha a fájlátvitelt folyamatnak tekintik, a letöltési és továbbítási mód csak a fájlátvitel befejezéséig használható. A várakozási időt befolyásolja az átviteli sebesség és a vevő kapacitása; A közvetítést közvetítés közben használják. A streaming média technológia lehetővé teszi az első próbavizsgát, hogy képes legyen hallgatni a TV-programokat az interneten anélkül, hogy hosszú letöltési időt várna. Ez a mód nagyon hasonlít a hagyományos műsorszóráshoz és a TV-műsorokhoz, és az internetes média hatását is jelenti a hagyományos műsorszórásra és a televíziós médiára. A streaming média weboldal fejlesztése a streaming média technológián alapul, amely egyesíti a streaming média fájlokat a weboldalakkal a streaming média fájlok weboldalakon keresztül történő lejátszásához.
2. A streaming média technológia fogalma
A streaming olyan átviteli technológia, amely audio és video információkat rögzített sebességgel továbbít a hálózati terheléstől függetlenül a feladó és a vevő között. A streaming média jellemzői az implicit idődimenzió, a valós idejű átvitel és a nagy áteresztőképesség. A streaming média technológia olyan technológia, amely streaminget használ a folyamatos, időalapú média továbbításához. A streaming mód a videó, audio és egyéb adathordozók tömörítési csomagokba tömörítése, és a streaming szerver valós időben továbbítja azokat a felhasználóknak. Az ügyfél úgy kezdheti meg a játékot, hogy a lejátszáshoz elég video csomagot tárol.
3. Általános streaming fájlformátumok
A hálózaton alkalmazott médiafájlok formátuma nagyon eltér a számítógépes alkalmazásokétól. Például az MPEG-1, mint VCD szabvány, használható a kép SIF standard felbontásához (352 NTSC rendszerhez) × 240, 352 PAL × 288 képéhez), és az átviteli sebesség 1.5 Mbps. De ezt az arányt a hálózati felhasználók nehezen tudják elérni. Tehát a népszerű streaming média technológia olyan technológia, amelynek célja az internet alacsony sávszélessége és átviteli minősége. Főleg a "másodlagos" feldolgozást követően teszi közzé a multimédia fájlformátumot. Magában foglalja a megszerzést, kódolást, továbbítást, tárolást és dekódolást. A streaming média alkalmazás rendszer általában három részre oszlik: kódoló vég, szerver oldal és kliens. Az internetes technológia fejlődésétől eltérően a streaming média rendszer fejlesztése még mindig a gyártók szokásos szakaszában van.
4. Streaming média átviteli technológia
A tároló audio és video adatfolyam alkalmazásakor az ügyfél tömörített audio és video fájlokat kér a szerveren. Ez a szerver lehet közös webszerver vagy streaming médiaszerver, amely az audio és video streaming szolgáltatásainak nyújtására irányul. A szerver audio- és videofájlokat küld az ügyfélhez csatlakozó aljzatba. A TCP és az UDP aljzatok is elérhetik ezt a funkciót. Mielőtt fájlokat küldene a hálózatra, a fájlokat szegmentáljuk és speciális fejlécekkel kapszulázzuk, hogy illeszkedjenek a fájlátvitelhez. A valós idejű protokoll (RTP) egy általános tartományi szabvány, amely a fenti szegmenseket foglalja magában. Amint az ügyfél megkezdi a kért audio- és videofájlok lejátszását, néhány másodperc múlva elkezdi lejátszani. Az interakciós funkció szüneteltetéssel, folytatással és a játékidő ugrásával fejeződik be.
A felhasználók internetes böngészőn keresztül kérik a hang és videó streaming használatát, de mivel a lejátszásuk nincs integrálva az ügyfélbe, a fájlok lejátszásához másodlagos alkalmazásra van szükség - médialejátszókra, például a valós hálózat valódi lejátszójára és a Microsoft Windows médialejátszójára. A médialejátszó a következő funkciókat látja el:
(1) Dekompresszió, a tárhely és a hálózati sávszélesség megtakarítása érdekében az audio és a kép általában tömörítve van. A médialejátszót lejátszás közben le kell tömöríteni.
(2) Távolítsa el a jitter csoportokat. A jitter a különbség a csomagok késésében az adatfolyamban forrástól célig. Mivel a hangot és a videót egyszerre kell lejátszani, a vevőnek rövid időre gyorsítótárba kell tennie a fogadott csomagokat, hogy kiküszöbölje a rázkódást.
(3) Hibajavítás. A kiszámíthatatlan internetes torlódások miatt a csomagkapcsolt adatfolyam egy része elveszhet. Ha a klip nagyon nagy, a felhasználók nem fogják elfogadni a hang és videó minőségét. Sok streaming rendszer megpróbálja helyreállítani az elveszett adatokat. Vagy rekonstruálják az elveszett csomagokat redundáns csomagok továbbításával, vagy közvetlenül kérik a csomagok újraküldését, vagy következtetnek és beillesztik az elveszett adatokat a fogadott adatokból.
(4) Felhasználói felület vezérlő részekkel. Ez a felhasználó operatív része, beleértve a hangerő szabályozását, a szünet / folytatás gombokat, az időugrás csúszkát stb.
Az audio- és videofájlokat a webszerveren tárolják, és HTTP-n keresztül elküldik az ügyfélnek, vagy a streaming szerveren nem HTTP-n keresztül küldik el az ügyfélnek.
A rendszer működési folyamata a következő:
(1) A webböngésző TCP kapcsolatot létesít a webszerverrel, és audio- és videofájlokat kérő HTTP-kérési üzenetet küld.
(2) A webszerver audio- és videofájlokkal ellátott HTTP-válaszüzenetet küld a böngészőnek.
(3) A HTTP válaszüzenet tartalomtípus fejléces sora deklarálja a megadott audio és video kódolást. Az ügyfélböngésző elemzi a válaszüzenet tartalmi típusát, felhívja a megfelelő médialejátszót, és továbbítja a fájlt a médialejátszónak.
(4) A médialejátszó elkezdi lejátszani a fájlt.
Az ilyen médialejátszás problémája, hogy a médialejátszónak a webböngésző közvetítésével kell interakcióba lépnie a szerverrel. Ez megköveteli, hogy a teljes fájlt teljesen le kell tölteni, mielőtt át lehetne adni a médialejátszónak lejátszás céljából. Nagyobb fájlok esetében a lejátszás előtti késést nehéz elfogadni. Ezért egy ilyen alkalmazásnak közvetlen socket kapcsolatot kell létrehoznia a szerver és a médialejátszó folyamata között, amely közvetlenül a szerverről a médialejátszóra irányul.
A metafájlok olyan fájlok, amelyek audio- és videofájlok streaming adatait nyújtják (például URL, kódolási típus). A webszerver hangot / videót közvetlenül a médialejátszóra küld. A közvetlen TCP-kapcsolat létrehozásának folyamata a következő:
(1) A felhasználó rákattint az audio / video fájl hivatkozásra.
(2) Ez a link nem közvetlenül egy audio / video fájlra irányul, hanem egy metafájlra. Ez a metafájl tartalmazza a tényleges audio / video fájl URL-jét. A válaszüzenet ezt a metafájlt foglalja magában, beleértve a tartalomtípus fejlécét is, deklarálva a megadott audio / video fájlt.
(3) Az ügyfélböngésző elemzi a válaszüzenet tartalomtípusának fejlécét, felhívja az érintett médialejátszót, és továbbítja a válaszüzenet teljes jelentésstílusát a médialejátszóhoz.
(4) A médialejátszó TCP kapcsolatot létesít közvetlenül a HTTP szerverrel. A médialejátszó HTTP üzenetet küld, amelyben audio / video fájlokat kér a TCP kapcsolathoz.
(5) A fájlt HTTP válaszüzenettel küldik a médialejátszónak, és a médialejátszó elkezd streamelni.
A metafájlok megszerzésének közbenső lépése nagyon fontos. Amikor a böngésző ismeri a fájl tartalmi típusát, felhívhatja a megfelelő médialejátszót, majd a médialejátszó közvetlenül kommunikál a szerverrel.
A médialejátszók fenti két architektúrája átengedi a HTTP-t, így a szerverrel TCP-n keresztül kommunikálnak. A HTTP nem képes teljes mértékben megvalósítani a felhasználók és a szerverek közötti interakciót, főleg nem könnyű a felhasználóknak (médiaszerveren keresztül) szüneteltetést, folytatást és gyorsparancsokat küldeniük a szerverre.
A HTTP és a TCP elkerülése érdekében a streaming szerverek használhatók audió és videó átvitelére a médialejátszókra. A streaming szerver általában a gyártó által gyártott streaming szerver, például helix szerver és Windows media server. A streaming szerveren keresztül az alkalmazásréteg protokoll használható audio és video küldésére UDP-n keresztül. Az alkalmazásréteg protokoll inkább alkalmas audio- és videofolyamokra, mint a http.
Ehhez az architektúrához két szerver szükséges, az egyik a HTTP szerver, amely a weboldalakat (a metafájlokat is beleértve) kezeli; A második a streaming szerver, amely audio és video fájlokat kezel. Két szerver futtatható egy végrendszerben vagy két független végrendszerben. A munkafolyamat hasonló az előzőhöz. De itt a médialejátszó a streaming szervertől kéri az adatokat, nem pedig a web szervertől. A médialejátszó és a streaming szerver kölcsönhatásba léphet saját protokolljával. Ezek a protokollok megkönnyíthetik a felhasználók interakcióját az audio- és videofolyamokkal.
5. Streaming média információk közzététele a weboldalon
A fájlinformációk közzétételének alapvető lépései a következők:
(1) Forrásfájlok készítése, általában audio és video programok rögzítése kamerákkal.
(2) A tartalom átkerül a számítógépre, és megvalósul a kép digitális formátumú rögzítése.
(3) A videoszerkesztő szoftvert a kép tartalmának szerkesztésére használják felirattal vagy háttérzenével.
(4) Videofájlok konvertálása. A felhasználók különböző igényeinek kielégítése érdekében át kell alakítanunk a szerkesztett videofájlokat a streaming médiafájlok különböző formátumaiba. Például az MPEG formátumot RM formátumra konvertálja.
(5) Konfigurálja a szükséges kliens és szerver szoftvert a videoadatok kiadásának megkönnyítése érdekében. Különböző streaming fájlokat különböző kliensekkel kell konfigurálni a lejátszáshoz.
Számos hálózati alkalmazásban a valódi rendszer népszerűbb. Az RM fájl a valódi streaming média magja, a helix producer a legfontosabb szoftver a valódi streaming média gyártási folyamatában. A helix gyártó által generált streaming média fájlok a helix szerver tartalmi könyvtárába kerülnek, amelyek igény szerint megvalósíthatók. Ha kódolja és azonnal elküldi a helix szervernek, akkor az élő közvetítés funkció megvalósítható. Ezenkívül a helix producer más multimédiás fájlformátumokat is konvertálhat valós streaming fájlokká.
A Helix producer plus9 képes konvertálni más multimédia fájlokat valódi streaming médiumokká, élő audio és video valódi streaming médiumokká, és elküldhető a helix szerverre is élő közvetítés céljából a kódolással egyidejűleg.
Ø 【Audio mód] három módot tartalmaz: zene, hang és nincs hang, amelyet főleg a hang hatásának beállítására használnak. Vegyes vagy magas szintű audio esetén a "zene" mód jobb.
Ø 【A videó mód magában foglalja a "normál mozgás videó", a "nagy gomb kép", a "sima mozgás", a "dia kijelző" és a "nincs videó" módot. Ha sok mozgókép van a videóban, a "normál mozgókép" módot kell választani; Ha nagy felbontást szeretne, választhatja a "nagy gomb képét"; Ha azt szeretné, hogy a kép átmenete gördülékenyebb legyen, kiválaszthatja a sima mozgás módot; Az állókép-előállítás kapcsolási hatásához csak a nagy felbontás tartható fenn. Ekkor kiválasztható a „diavetítés” mód.
Ø 【Video encoder] háromféle kódolót tartalmaz: a realvideo G2 SVT-vel, a realvideo 8 és a realvideo 9. Bármilyen bitsebesség mellett a realvideo 9 kódolással érhető el a legjobb videóhatás.
Ø 【A SureStream funkció a közönség kiválasztása] oszlopban ugyanazt a hang- és videotartalmat több különböző sebességgel továbbíthatja. Be vannak építve egy streaming médiafájlba, amely spontán módon elküldi a megfelelő tartalmat a célközönség hálózati sebességének megfelelően.
A weboldalról a valódi streaming adathordozóra mutató link nem közvetlenül az RM fájlhoz, hanem ram fájlhoz kapcsolódik. Ha a valós streaming média be van ágyazva a weboldalba, akkor azt RPM fájl valósítja meg.
Amikor a felhasználók a valós szerveren található streaming fájlra mutató linkre kattintanak, sok böngésző eredeti beállításai miatt nem indítja el a RealPlayer programot másodlagos lejátszóként. A Real rendszer egy köztes fájlt (RAM fájlt) biztosít, amely segíti az ügyfélrendszert a RealPlayer elindításában.
A Ram fájl egyszerű szöveges fájl, fájlkiterjesztése pedig. Ram. A ram fájlban felsorolja a lejátszani kívánt streaming fájl URL-címét. Amikor a felhasználói böngésző ram fájlt tölt be, a RealPlayer indul másodlagos lejátszóként. A RealPlayer automatikusan átmásolja a médiafájlt a ram fájl URL-címe szerint a lejátszáshoz.
Weboldal írásakor az igazi streaming adathordozót a ram fájl aktiválja úgy, hogy a helix szerveren vagy a webszerveren lévő ram fájlhoz a szokásos linken keresztül kapcsolódik. Például:
A Ram.htm fájl
<cím> link ram fájl
és test.rpm A dokumentumok a következők:
http://127.0.0.1/realvideo.rm
Futtassa a böngésző rpm.htm fájljával, a RealPlayer lejátszó beágyazódik a böngésző oldalába.
6. A streaming média webhelyének telepítése
Az egyes gyártók streaming médiarendszereinek megvannak a saját jellemzői, de a fő összetevők négy részből állnak: média kódoló, média fájl memória, média szerver és médialejátszó. A négy rész együttműködik a streaming média szolgáltatási rendszer kialakításában. A rendszer architektúráját és kapcsolatát a 4. ábra mutatja
Ø Média kódoló. Az eredeti médiafájlokat vagy a kamera által összegyűjtött valós idejű médiaadatokat hálózati formátumba (stream formátumba) készítik, amely alkalmas hálózati továbbításra, majd a streaming fájlokat a médiafájl memóriájában tárolják, vagy közvetlenül elküldik a streaming médiaszerverre .
Ø Médiafájl memória. A tárolási adatfolyam formátumú médiafájlok általában SCSI merevlemezek vagy lemeztömbök.
Ø Médiaszerver. Az ütemező kiszolgáló által a webkiszolgálóról továbbított felhasználói kérelemre válaszul a streaming fájl a hálózati átviteli protokollon keresztül kerül a felhasználói asztalra.
Ø Médialejátszó. Fogja a hálózati médiaadatokat és játssza le őket helyben.
A terheléselosztás és a több felhasználó támogatása érdekében a médiaszerver általában felépít egy LAN-fürtöt és elvégzi az NBP képfeldolgozását. A felügyeleti kiszolgáló felhasználói kéréseket küld a legkisebb terhelésű szervernek, az egyes szerverek terhelési állapotának megfelelően. A felügyeleti kiszolgáló felelős a streaming médiafájlok kezeléséért, a digitális szerzői jogok kezeléséért stb. A streaming szolgáltatások portál webhelye továbbra is webszerver.
7. A streaming média továbbításának minőségellenőrzése
Az adatátvitel minőség-ellenőrzése a legfontosabb tényező, amely korlátozza a streaming médiaszolgáltatások teljesítményét, és a streaming médiaszolgáltatók elsődleges gondja is. Vagyis a meglévő hálózati sávszélesség alatt hogyan lehet minél több egyidejű támogatni, és hogyan garantálható a végpontok közötti streaming média QoS.
A lehető legtöbb egyidejű felhasználó támogatása, valamint a kiszolgáló terhelésének és a QoS csökkentésének elkerülése érdekében a nagyszámú egyidejű szám miatt a rendszernek a hálózati forgalom és az egyidejű szám kezelésére és korlátozására van szükség.
A fenti három mutató közötti kapcsolatnak meg kell felelnie a következő követelményeknek: maximális hálózati sávszélesség / maximális egyidejűség száma ≤ maximális egyfolyamú sebesség. A fenti indexek meghatározásának módszerei különböznek a gyártók streaming médiatermékei esetében. Néhányan közvetlenül a szerver oldalon vannak beállítva; Néhányat a licencmechanizmus állít be, de a tényleges értékek továbbra is a szerver teljesítményéhez kapcsolódnak.
A streaming médiaszolgáltatás egyfajta szélessávú szolgáltatás, amelynek magas követelményei vannak a hálózati sávszélességre, a jitterre, a késleltetésre és a csomagveszteségre. A jobb QoS biztosítása érdekében számos érett sávszélesség-adaptációs és minőség-ellenőrzési technológiát fejlesztettek ki a streaming média területén.
Ø Intelligens áramlási technológia. A rendszer automatikusan felismeri a hálózati állapotot, és a lehető legjobban beállítja az audio- és videofolyam attribútumait, hogy a felhasználók a lehető legjobb felhasználói élmény érdekében a csatlakozási sebességnek megfelelő médiafolyamot fogadhassák. A cikk lényege, hogy a c / s modell alkalmazási rétegének sebesség-visszacsatolási mechanizmusán keresztül észlelje a hálózati sávszélesség változását, és a médiafolyam átviteli sebességét dinamikusan állítsa be a szerver oldalon a média többsebességű hierarchikus kódolási képességének felhasználásával adatfolyamot, annak biztosítása érdekében, hogy a felhasználók a hálózati sávszélesség-változás feltételei mellett továbbra is jobb minőségű médiafolyamot kapjanak.
Ø Split technológia. Általában az internetes élő közvetítésben használják. A küldő szerver az élő média streamet küldi az egész világon elosztott több fogadó szervernek UDP unicast és multicast útján. Az ügyfél hozzáférhet a közeli szerverhez, hogy kiváló minőségű médiafolyamot kapjon, és csökkentse a sávszélesség használatát. A tolatás és a húzás kétféle módja van.
Ø Tartalomelosztó hálózati technológia (CDN). Az IP-hálózaton alapuló tartalmi átfedő hálózatként az aktív tartalomkezelés, a globális terheléselosztás és a tartalom-gyorsítótár bevezetésével közzéteheti a felhasználók által kért streaming médiatartalmat a felhasználó legközelebbi hálózati szélén, hogy javítsa a felhasználó hozzáférési válaszsebesség, hatékonyan megoldja a hálózati torlódásokat és minimalizálja a gerinchálózat forgalmát.
Ø gyorsítótár. Mivel az internet nem folyamatos aszinkron csomagátvitelen alapul, a valós idejű médiafolyamot vagy médiafájlt több csomagra osztjuk továbbítás céljából. A hálózati késedelem, rázkódás és egyéb tényezők miatt az ügyfélhez érkező csomagok sorrendje és késése eltérő lehet, és előfordulhat a csomagok érkezés előtti elküldése. Ezért a gyorsítótár-rendszerre van szükség a hálózati késleltetés és a rázkódás hatásának pótlására, hogy biztosítsák az adatcsomagok helyes sorrendjét és a lejátszási szünet jelenségét a hálózati átmeneti torlódások miatt. A gyorsítótár-technológia magában foglalja az előre-, a fordított- és az átlátszó proxy-gyorsítótár-technológiát
|
|
|
|
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: |
|
