Viimastel aastatel on kasvav nõudlus mitme platvormi kohandamise järele toonud kaasa voogedastuse adaptiivse bitikiirusega taasesituse, mis on sundinud veebi- ja mobiiliarendajaid videotehnoloogia loogikat ümber mõtlema. Kõigepealt andsid hiiglased välja HLS-, HDS- ja Smooth Streaming -protokollid eraldi, peites kõik asjakohased üksikasjad oma spetsiaalsetesse SDK-desse. Arendajad ei saa pleieris multimeediumimootori loogikat vabalt muuta: te ei saa muuta kohanduva bitikiiruse ja vahemälu suuruse reegleid ega isegi viilude pikkust. Neid mängijaid võib olla lihtne kasutada, kuid teil pole selle kohandamiseks liiga palju võimalusi ja isegi halbu funktsioone saab lubada.
Kuid erinevate rakendusstsenaariumide suurenemisega muutub nõudlus kohandatavate funktsioonide järele järjest tugevamaks. Otseülekannete ja tellitavate toodete vahel on puhvrihalduses, ABR-i strateegiates ja vahemällu salvestamise strateegiates erinevusi. Need nõuded sünnitasid rida madalama taseme multimeediaoperatsioonide API-sid: Netstream Flashil, Media Source Extensions HTML5-l ja Media Codec Androidil. Samal ajal ilmus tööstuses tavaline HTTP-põhine voogesitusvorming MPEG-DASH. . Need täiustatud võimalused pakuvad arendajatele suuremat paindlikkust, võimaldades neil ehitada mängijaid ja multimeediumimootoreid, mis vastavad nende ärivajadustele.
Täna jagame, kuidas moodsat mängijat ehitada ja milliseid põhikomponente on sellise mängija ehitamiseks vaja. Üldiselt võib tüüpilise mängija jagada kolmeks osaks: kasutajaliides, multimeediumimootor ja dekooder.
Kasutajaliides (UI): see on mängija ülemine osa. See määratleb lõppkasutaja vaatamiskogemuse kolme erineva funktsionaalse omaduse kaudu: nahk (mängija välimus), kasutajaliides (kõik kohandatavad funktsioonid, nagu esitusloendid ja sotsiaalne jagamine jne) ja äriloogika (konkreetne äriloogika). reklaamide, seadmete ühilduvuse loogika ja sertifitseerimise haldamine jne).
Multimeediumimootor: see haldab kogu taasesituse juhtimisega seotud loogikat, näiteks kirjeldusfailide analüüsi, videoklippide tõmbamist ning adaptiivsete bitikiiruse reeglite seadistamist ja vahetamist. Seda osa selgitame üksikasjalikult allpool. Kuna need mootorid on üldiselt platvormiga tihedalt seotud, võib kõigi platvormide katmiseks osutuda vajalikuks kasutada erinevaid mootoreid.
Dekooder ja DRM-haldur: mängija madalaim osa on dekoodri ja DRM-i haldur. Selle kihi funktsioonid kutsuvad otse operatsioonisüsteemi poolt eksponeeritud API-sid. Dekoodri põhiülesanne on videosisu dekodeerimine ja renderdamine, DRM-haldur aga kontrollib, kas tal on õigus dekrüpteerimisprotsessi kaudu mängida.
Järgmisena kasutame näiteid, et tutvustada iga kihi erinevaid rolle.
1. Kasutajaliides (UI)
Kasutajaliidese kiht on mängija ülemine kiht. See kontrollib, mida teie kasutajad saavad näha ja millega suhelda. Samal ajal saate seda oma kaubamärgiga kohandada, et pakkuda kasutajatele ainulaadset kasutuskogemust. See kiht on kõige lähemal esiosa arendusosale, millest räägime. UI-sse lisame ka äriloogika komponendid, mis moodustavad teie taasesituse kogemuse ainulaadsuse, kuigi lõppkasutaja ei saa funktsiooni selle osaga otse suhelda.
Kasutajaliidese osa sisaldab peamiselt kolme komponenti:
1) Nahk
Nahk on mängija visuaalselt seotud osade üldine mõiste: edenemise juhtimisribad, nupud, animeeritud ikoonid jne, nagu on näidatud joonisel 2. Nagu enamik kujunduskomponente, on ka selle komponendi osa rakendatud CSS-i abil, mis võimaldab disainerid või arendajad saavad neid hõlpsasti integreerida (isegi kui kasutate terviklikku lahendust, näiteks JW Player ja Bitdash).
2) kasutajaliidese loogika
Kasutajaliidese loogikaosas määratletakse kõik nähtavad interaktsioonid taasesituse ja kasutajate interaktsiooni ajal: esitusloendid, pisipildid, taasesituskanalite valik ja sotsiaalmeedia jagamine. Lähtudes eeldatavast taasesituskogemusest, võib sellele osale minevikus lisada palju muid funktsioone, millest paljud eksisteerivad pistikprogrammidena ja võib-olla leiate inspiratsiooni: pistikprogrammid · videojs / video.js Wiki · GitHubi loogikaosa Komplektis on palju funktsioone. Me ei tutvusta neid üksikasjalikult, vaid võtame näiteks nende funktsioonide intuitiivseks kogemiseks Eurospordi mängija kasutajaliidese.
Lisaks traditsioonilistele kasutajaliidese elementidele on ka väga huvitav funktsioon. Kui kasutaja vaatab DVR-voogesituse meediumit, kuvatakse otseülekanne väikese akna kujul ja publik saab selle väikese akna kaudu igal ajal otseülekande juurde naasta. Kuna paigutus või kasutajaliides ja multimeediumimootor on täiesti sõltumatud, saab neid funktsioone rakendada HTML5-s dash.js-i abil, kasutades vaid mõnda koodirida. Kasutajaliidese osas on parim viis selle rakendamiseks lisada kasutajaliidese põhimoodulitele pistikprogrammide / moodulite kujul erinevaid funktsioone.
3) Äriloogika
Lisaks ülaltoodud kahe osa "nähtavatele" omadustele on veel üks nähtamatu osa, mis moodustab teie ettevõtte ainulaadsuse: autentimine ja maksmine, kanalite ja esitusloendite hankimine ning reklaamimine. Samuti on mõned tehnoloogiaga seotud asjad, näiteks A / B testmoodulid ja seadmetega seotud konfiguratsioonid. Neid konfiguratsioone kasutatakse mitme erineva meediumimootori valimiseks erinevat tüüpi seadmete hulgast.
Altpoolt peidetud keerukuse paljastamiseks selgitame neid mooduleid üksikasjalikumalt siin:
Seadme tuvastamise ja seadistamise loogika: see on üks olulisemaid funktsioone, kuna see eraldab taasesituse ja renderdamise. Näiteks võib teie brauseri erinevate versioonide põhjal mängija valida HLS-i videovoogude esitamiseks automaatselt HTML5 MSE-l, hls.js-il või välgupõhisel taasesitusmootoril FlasHls põhineva multimeediumimootori. Selle osa suurim omadus on see, et hoolimata sellest, millist alusmootorit kasutate, saate ülemise kihi kasutajaliidese või äriloogika kohandamiseks kasutada sama JavaScripti või CSS-i.
Võimalus tuvastada kasutajate seadmeid võimaldab teil vajaduse korral seadistada lõppkasutaja kogemusi: kui mängite 4K ekraaniseadme asemel mobiilseadmes, peate võib-olla alustama väiksema bitikiirusega.
A / B-testi loogika: A / B-test peab olema osade kasutajate jaoks tootmisprotsessis hall. Näiteks võite mõnele Chrome'i kasutajale anda uue nupu või uue multimeediumimootori ning samuti saate tagada, et kogu selle töö jätkub plaanipäraselt.
Reklaam (valikuline): reklaami töötlemine kliendipoolel on üks keerulisemaid äriloogikaid. Nagu on näidatud pistikmooduli videojs-contrib-ads reklaamide vooskeemil, on reklaamide sisestamise protsessis mitu sammu. HTTP-video voogesituse jaoks kasutate enam-vähem mõnda olemasolevat vormingut, näiteks VAST, VPAID või Google IMA, mis võivad aidata teil videoreklaame reklaamiserverist tõmmata (tavaliselt vananenud mittetundlikud vormingud), paigutatud alguses, keskel ja video taasesituse hilises staadiumis ja seda ei saa vahele jätta.
kokku võtma:
Kohandamisvajaduste jaoks võite kasutada mängimiseks kõiki klassikalisi funktsioone sisaldavat JW Playerit (see võimaldab teil ka mõningaid funktsioone kohandada) või kohandada omaenda funktsioone, lähtudes avatud lähtekoodiga mängijast, näiteks Videojs. Isegi brauseri ja emapleieri vahelise kasutuskogemuse ühtlustamiseks võite kaaluda ka React Native'i kasutamist kasutajaliidese või naha arendamiseks ja Haxe äriloogika arendamiseks. Neid suurepäraseid teeke võib olla mitut tüüpi. Seadmete vahel jagatakse sama koodibaaside kogumit.
2, multimeediumimootor
Viimastel aastatel on multimeediumimootor mängija arhitektuuris ilmunud uue iseseisva komponendina. MP4 ajastul töötles platvorm kogu taasesitusega seotud loogikat ja arendajatele avati ainult mõned multimeedia töötlemisega seotud funktsioonid (ainult sellised funktsioonid nagu taasesitus, paus, lohistamine ja täisekraanrežiim).
Uus HTTP-põhine voogesitusmeedia formaat nõuab aga uue keerukuse käsitlemiseks ja juhtimiseks täiesti uut komponenti: deklaratsioonifailide sõelumine, videoklippide allalaadimine, adaptiivne bitikiiruse jälgimine, otsuste tegemise tähis ja palju muud. Alguses tegeles ABR-i keerukusega platvorm või seadmete pakkuja. Suureneva nõudega ankrukontrolli ja kohandatud mängijate järele on mõned uued mängijad siiski järk-järgult avanud mõned madalama taseme API-d (näiteks meediumiallika laiendused veebis, Netstream Flashil ja meediumikoodek Androidi platvormil) ning kiiresti meelitanud palju tugevaid ja jõulisi multimeediumimootoreid, mis põhinevad neil API-l.
Järgmisena selgitame üksikasjalikult kaasaegse multimeediumitöötlusmootori iga komponendi üksikasju:
1) Deklaratsioonifaili tõlgendamine ja parser
HTTP-põhises video voogesituses algab kõik kirjeldusfailist. Deklaratsioonifail sisaldab metainfot, millest meediumiserver peab aru saama: mitu erinevat tüüpi video kvaliteeti, keelt ja tähti jne ning mis need on. Parser hankib kirjeldusteabe XML-failist (spetsiaalne m3u8 fail HLS-i jaoks) ja seejärel saab teabest õige videoteabe. Muidugi on meediumiservereid mitut tüüpi ja mitte kõik neist ei rakenda spetsifikatsioone õigesti, mistõttu võib parseril tekkida vajadus tegeleda mõne täiendava rakendusveaga.
Kui videoteave on välja kaevatud, parseldab parser selle andmed voogesitatava visuaalse pildi koostamiseks ja teab, kuidas erinevaid videoklippe hankida. Mõnes multimeediumimootoris ilmuvad need visuaalsed pildid kõigepealt abstraktse multimeediumkujutise kujul ja joonistavad seejärel ekraanile erinevate HTTP-videovoogude vormingute erinevad omadused.
Otseülekande stseenis peab parser ka perioodiliselt deklaratsioonifaili uuesti omandama, et saada uusim videoklippide teave.
2) Allalaadija (laadige alla deklaratsioonifailid, multimeediumiklipid ja võtmed)
Allalaadija on moodul, mis ümbritseb natiivset API-d HTTP-päringute töötlemiseks. Seda ei kasutata mitte ainult multimeediumifailide allalaadimiseks, vaid seda saab vajadusel kasutada ka deklaratsioonifailide ja DRM-võtmete allalaadimiseks. Allalaadija mängib võrguvigade käsitlemisel väga olulist rolli ja proovib uuesti, samal ajal kui on võimalik andmeid koguda praegu saadaoleva ribalaiuse kohta.
Märkus. Multimeediumifailide allalaadimisel võib punkt-punkt reaalajas suhtlusstsenaariumis kasutada HTTP-protokolli või muid protokolle, näiteks WebRTC-protokolli.
3) voogesituse mootor
Voogesituse taasesitusmootor on keskne moodul, mis suhtleb dekooderi API-ga. See impordib koodrisse erinevaid multimeediumiklippe ja tegeleb mitmekordse vahetamise ning erinevustega taasesituse ajal (näiteks deklaratsioonifailide ja videolõikude erinevus ning automaatne külmutamine). Raami vahelejätmine).
4) Ressursikvaliteedi parameetri ennustaja (ribalaius, protsessor, kaadrisagedus jne)
Hindaja saab andmeid erinevatest mõõtmetest (ploki suurus, allalaadimisaeg fragmendi kohta ja vahele jäetud kaadrite arv) ning koondab need kasutajate käsutuses oleva ribalaiuse ja protsessori arvutusvõimsuse hindamiseks. Seda väljundit kasutatakse ABR-i (Adaptive Bitrate, adaptive bitrate) lülitamise kontrolleril otsuste tegemiseks.
5) ABR-lüliti kontroller
ABR-lüliti võib olla multimeediumimootori kõige kriitilisem osa - tavaliselt kõige tähelepanuta jäetud osa. Kontroller loeb hindaja väljundis olevaid andmeid (ribalaius ja vahelejäetud kaadrite arv), kasutab kohandatud algoritmi nende andmete põhjal hinnangute andmiseks ja ütleb voogedastusmootorile, kas peab vahetama video- või helikvaliteeti. Selles valdkonnas on palju uurimistööd ja suurimaks raskuseks on tasakaalu leidmine puhverdamise riski ja vahetamise sageduse vahel (liiga sagedane vahetamine võib põhjustada halba kasutajakogemust).
6) DRM-haldur (valikuline komponent)
Täna põhinevad kõik tasulised videoteenused DRM-i haldusel ja DRM sõltub suuresti platvormist või seadmetest, näeme, kui mängijat hiljem selgitame. Multimeediumimootori DRM-haldur on alumise taseme dekooderis oleva sisu dekrüpteerimise API ümbris. Võimaluse korral püüab see brauserite või operatsioonisüsteemide rakendamise üksikasjade erinevusi varjata abstraktselt. See komponent on tavaliselt tihedalt ühendatud voo töötlemise mootoriga, kuna see suhtleb sageli dekoodri kihiga.
7) Teisenda multiplekseri vorming (valikuline komponent)
Nagu hiljem näeme, on igal platvormil pakendamise ja kodeerimise osas oma piirangud (Flash loeb FLV konteineritesse kapseldatud H.264 / AAC-faile ja MSE loeb ISOBMFF-i konteineritesse kapseldatud H.264 / AAC-faile. Fail). See toob kaasa mõned videoklipid, mis tuleb enne dekodeerimist vormindada. Näiteks MPEG2-TS-st ISOBMFF-i vormindamise multiplekseriga saab hls.js kasutada MSS-vormingus sisu HLS-i videovoogude esitamiseks. Multimeediumimootori tasemel vormingu teisendamise multiplekser on kahtluse alla seatud; kaasaegse JavaScripti või Flashi tõlgendusvõime täiustamisel on selle kaasnev jõudluskaotus aga peaaegu tühine ja see ei avalda kasutuskogemusele suurt mõju.
kokku võtma
Multimeediumimootoris on ka palju erinevaid komponente ja funktsioone, alates subtiitritest kuni ekraanipiltideni kuni reklaami sisestamiseni ja nii edasi. Järgmisena kirjutame ka eraldi artikli, et võrrelda erinevate mootorite erinevusi, läbi mõningate testide ja turuandmete, et anda mootori valimiseks sisulisi juhiseid. Väärib märkimist, et erinevate platvormidega ühilduva mängija ehitamiseks on väga oluline pakkuda mitut vabalt vahetatavat multimeediumimootorit, sest selle aluseks olev dekooder on seotud kasutaja platvormiga. Järgmisena keskendume sellele aspektile.
3. Dekooder ja DRM-haldur
Dekodeerimise jõudluse (dekooder) ja turvalisuse kaalutlustel (DRM) on dekooder ja DRM-haldur tihedalt seotud opsüsteemi platvormiga.
1) Dekooder
Dekooder haldab alumise kihi taasesitusega seotud loogikat. See pakib videod lahti erinevates kapseldamisvormingutes, dekodeerib nende sisu ja toimetab dekodeeritud videokaadrid renderdamiseks operatsioonisüsteemi ning võimaldab lõpuks ka lõpptarbijatel näha.
Kuna videotihenduse algoritmid muutuvad üha keerukamaks, on dekodeerimisprotsess protsess, mis nõuab intensiivseid arvutusi ning dekodeerimise jõudluse ja sujuva taasesituse kogemuse tagamiseks peab dekodeerimisprotsess olema tugevalt sõltuv operatsioonisüsteemist ja riistvarast. Suurem osa praegusest dekodeerimisest toetub GPU kiirendatud dekodeerimisele (see on ka üks põhjus, miks tasuta ja võimsam VP9 dekooder pole võitnud H.264 turupositsiooni). Kui GPU kiirendust pole, võtab 1080P video dekodeerimine protsessori arvutusest umbes 70% ja kaadrikadu võib olla väga tõsine.
Videoraamide dekodeerimise ja renderdamise põhjal pakub haldur ka natiivset puhvrit. Multimeediumimootor saab puhvriga otse suhelda, et mõista selle suurust reaalajas ja vajadusel seda värskendada.
Nagu me varem mainisime, on igal platvormil oma renderdamismootor ja vastav API: Flash-platvormil on Netstream, Android-platvormil on Media Codec API ja veebis on tavalised meediumiallikate laiendused. MSE on üha enam pilkupüüdev ja võib tulevikus muutuda brauseri järel teistele platvormidele de facto standardiks.
2) DRM-i haldur
Täna on DRM vajalik stuudiote toodetud tasulise sisu edastamisel. Selle sisu varastamist tuleb takistada, seega on DRM-i kood ja tööprotsess lõppkasutajatele ja arendajatele blokeeritud. Dekrüpteeritud sisu ei lahku dekodeerimiskihist, mistõttu seda ei võeta pealt.
DRM-i standardiseerimiseks ja teatava koostalitlusvõime tagamiseks erinevate platvormide juurutamiseks lõid mitmed veebihiiglased ühise krüptimise (CENC) ja universaalse multimeediumkrüptimislaiendi Krüptitud meediumilaiendid, et pakkuda mitut DRM-i pakkujat (näiteks võib EME-d kasutada Playready Edge'i platvormil ja Widewine Chrome'i platvormil, et luua levinud API-de komplekt, mis saab dekrüpteerimiseks lugeda DRM-i autoriseerimismoodulist videosisu krüptovõtit.
CENC kuulutas välja standardsete krüptimis- ja võtmekaardistamismeetodite komplekti, mida saab kasutada sama sisu dešifreerimiseks mitmes DRM-süsteemis, pakkudes ainult sama võtit.
Brauseri sees saab videosisu metainfo põhjal EME tuvastada, millist DRM-süsteemi krüptimiseks kasutatakse, ja helistada vastavasse dekrüpteerimismoodulisse (Content Decryption Module, CDM) CENC-i poolt krüptitud sisu dekrüpteerimiseks. Dekrüptimismoodul CDM tegeleb sisu autoriseerimisega seotud töödega, hankib võtme ja dekrüpteerib videosisu.
CENC ei määra autoriseerimise väljaandmist, autoriseerimise vormingut, volituste salvestamise ja kasutamise reegleid ning lubade kaardistamise suhet ja muid üksikasju. Nende üksikasjade käitlemise eest vastutab DRM-i pakkuja.
4. kokkuvõte
Täna mõistame sügavalt videopleieri kolme taseme erinevat sisu. Parim osa sellest kaasaegsest mängijastruktuurist on see, et selle interaktiivne osa on täielikult eraldatud multimeediumimootori loogilisest osast, võimaldades ankrul kohandada lõpptarbija kogemusi sujuvalt, vabalt ja paindlikult. , Erinevate multimeediummootorite samaaegne kasutamine mitmel erineval lõppseadmel võib tagada mitmesuguste videosisu vormingute sujuva taasesituse.
Veebiplatvormil on tänu multimeediumimootorite nagu dash.js, Shaka Player ja hls.js abile, mis kipuvad olema küpsed teegid, muutumas MSE ja EME taasesituse uuteks standarditeks ning üha enam mõjukaid tootjaid kasutavad neid. Need taasesitusmootorid. Viimastel aastatel on tähelepanu hakanud laienema ka digiboksidele ja Interneti-teleritele ning oleme ka näinud, et üha rohkem selliseid uusi seadmeid kasutab multimeediumitöötlusmootorina MSE-d. Jätkame nende standardite toetamiseks rohkem jõupingutusi.
|
|
|
|
Kui kaugele (pikk) saatja katta?
Tegelik võimsus sõltub paljudest teguritest. Tõeline kaugus põhineb antenni paigaldamisel kõrgus, antennivõimendus, kasutades keskkonnas, nagu hoones ja muud takistused, tundlikkus vastuvõtja, antenn vastuvõtja. Paigaldamine antenn rohkem kõrge ja kasutades maal, kauguse palju kaugemale.
Näide 5W FM-saatja kasutamine linna ja kodulinna:
Mul on USA kliendile kasutamiseks 5W fm transmitter koos GP antenn oma kodulinnas, ja ta katsetada seda autot, see katab 10km (6.21mile).
Ma testida 5W fm transmitter koos GP antenn minu kodulinnas, seda katavad umbes 2km (1.24mile).
Ma testida 5W fm transmitter koos GP antenn Guangzhou linn, seda katavad umbes ainult 300meter (984ft).
Allpool on umbes vahemikus erineva võimsusega FM saatjad. (Vahemik on läbimõõduga)
0.1W ~ 5W FM saatja: 100M ~ 1KM
5W ~ 15W FM Ttransmitter: 1KM ~ 3KM
15W ~ 80W FM saatja: 3KM ~ 10KM
80W ~ 500W FM saatja: 10KM ~ 30KM
500W ~ 1000W FM saatja: 30KM ~ 50KM
1KW ~ 2KW FM saatja: 50KM ~ 100KM
2KW ~ 5KW FM saatja: 100KM ~ 150KM
5KW ~ 10KW FM saatja: 150KM ~ 200KM
Kuidas meiega ühendust võtta saatja?
Helista mulle + 8618078869184 OR
Saada mulle [meiliga kaitstud]
1.How kaugele sa tahad, et katta läbimõõduga?
2.How pikk teie torn?
3.Where sa pärit oled?
Ja me teile rohkem professionaalset nõu.
Meist
FMUSER.ORG on süsteemi integreerimisfirma, mis keskendub raadiovõrgu traadita andmeedastusele / stuudio video audio seadmetele / voogedastusele ja andmetöötlusele. Pakume kõike alates nõuandest ja konsultatsioonidest raami integreerimise ja paigaldamise, kasutuselevõtu ja koolituse kaudu.
Pakume FM-saatjat, analoogtelevisiooni saatjat, digitaaltelevisiooni saatjat, VHF-i UHF-saatjat, antenne, koaksiaalkaabliühendusi, STL-i, õhu töötlemisel, stuudio levitamistooteid, RF-signaali jälgimist, RDS-kodeerijaid, heliprotsessoreid ja kaug-saidi juhtseadmeid IPTV tooted, Video / Audio Encoder / Decoder, mis on ette nähtud nii suurte rahvusvaheliste ringhäälinguvõrkude kui ka väikeste erajaamade vajadustele.
Meie lahendusel on FM-raadiojaam / analoog-TV-jaam / digi-TV-jaam / audio-videostuudioseadmed / stuudiosaatja link / saatja telemeetriasüsteem / hotelli telesüsteem / IPTV-otseülekanne / voogesituse otseülekanne / videokonverents / CATV-ringhäälingusüsteem.
Me kasutame kõigi süsteemide jaoks kõrgtehnoloogilisi tooteid, sest me teame, et kõrge usaldusväärsus ja kõrge jõudlus on süsteemi ja lahenduse jaoks nii olulised. Samal ajal peame ka tagama, et meie toodete süsteem oleks väga mõistliku hinnaga.
Meil on avalike ja kaubanduslike ringhäälinguorganisatsioonide, telekommunikatsioonioperaatorite ja reguleerivate asutuste kliente ning pakume lahendusi ja tooteid ka sadadele väiksematele, kohalikele ja kogukondlikele ringhäälinguorganisatsioonidele.
FMUSER.ORG on eksportinud üle 15 aasta ja tal on kliente kogu maailmas. 13-aastase kogemusega selles valdkonnas on meil professionaalne meeskond kliendi igasuguste probleemide lahendamiseks. Pühendume professionaalsete toodete ja teenuste äärmiselt mõistliku hinna pakkumisel. Kontakt e-post: [meiliga kaitstud]
meie Factory
Meil on moderniseerimine tehases. Olete oodatud külastama meie tehases kui sa tuled Hiinas.
Praegu on juba 1095 kliendid üle maailma külastanud meie Guangzhou Tianhe kontoris. Kui sa tuled Hiinas, olete oodatud meile külla.
õiglases
See on meie osalemine 2012 Global Sources Hong Kong Electronics Fair . Kliendid üle kogu maailma Lõpuks on võimalus kokku saada.
Kus on Fmuser?
Võite neid numbreid otsida " 23.127460034623816,113.33224654197693 "Google'i kaardilt leiate meie fmuseri kontori.
FMUSER Guangzhou asukoht on Tianhe piirkond, mis on keskel Canton . väga lähedal Euroopa Canton Fair , Guangzhou raudteejaamas, xiaobei tee ja dashatou Ainult vaja 10 minuti kui võtta TAXI . Tere sõbrad üle maailma, et külastada ja rääkida.
Kontakt: Sky Blue
Mobiiltelefon: + 8618078869184
WhatsApp: + 8618078869184
Wechat: + 8618078869184
E-mail: [meiliga kaitstud]
QQ: 727926717
Skype: sky198710021
Aadress: No.305 Room HuiLan Building No.273 Huanpu Road Guangzhou Hiina Zip: 510620
|
|
|
|
Inglise: Aktsepteerime kõiki makseid, näiteks PayPal, krediitkaart, Western Union, Alipay, Money Bookers, T / T, LC, DP, DA, OA, Payoneer. Kui teil on küsimusi, võtke minuga ühendust [meiliga kaitstud] või WhatsApp + 8618078869184
-
PayPal.  www.paypal.com
Soovitame kasutada Paypal osta meie esemed, PayPal on turvaline viis osta Internetis.
Iga meie kaubaartiklite lehekülje allosas peal on paypal logo maksta.
Krediitkaart.Kui sul ei ole PayPal, kuid sa pead krediitkaarti, siis võib ka klõpsata Yellow PayPal nuppu maksma oma krediitkaardi.
-------------------------------------------------- -------------------
Aga kui sa ei ole krediitkaarti ja ei pea PayPal konto või raskelt sai paypal accout, võite kasutada järgmisi:
Western Union.  www.westernunion.com
Maksta Western Union mulle:
Eesnimi / eesnimi: Yingfeng
Perekonnanimi / perekonnanimi / perekonnanimi: Zhang
Täielik nimi: Yingfeng Zhang
Riik: Hiina
Linn: Guangzhou
|
-------------------------------------------------- -------------------
T / T. maksta T / T (pangaülekanne / telegrammülekanne / Bank Transfer)
Esimene Panga teave (ettevõtte konto):
SWIFT BIC: BKCHHKHHXXX
Panga nimi: HIINA (HONG KONG) BANK OF HONG KONG, HONG KONG
Panga aadress: HIINA TOBI BANK, 1 AED ROAD, CENTRAL, HONG KONG
PANGA KOOD: 012
Konto nimi: FMUSER INTERNATIONAL GROUP LIMITED
Arveldusarve nr. : 012-676-2-007855-0
-------------------------------------------------- -------------------
Teine Panga TEAVE (ETTEVÕTTE KONTO):
Saaja: Fmuser International Group Inc
Konto number: 44050158090900000337
Saaja pank: Hiina Ehituspanga Guangdongi filiaal
SWIFT-kood: PCBCCNBJGDX
Aadress: NO.553 Tianhe Road, Guangzhou, Guangdong, Tianhe piirkond, Hiina
** Märkus. Kui kannate raha meie pangakontole, ÄRGE kirjutage märkuste piirkonda midagi, vastasel juhul ei saa me valitsuse rahvusvahelise kaubanduse poliitika tõttu makset kätte.
|
|
|
|
* See saata 1-2 tööpäeva jooksul, kui makse selge.
* Saadame selle oma paypal aadressi. Kui soovite muuta aadress, saatke oma õige aadress ja telefoni number minu e-posti [meiliga kaitstud]
* Kui paketid on alla 2kg, me vedada posti teel lennupostiga, see võtab aega umbes 15-25days oma käsi.
Kui pakend on rohkem kui 2kg, me laeva kaudu EMS, DHL, UPS, FedEx kiire kullerpostiteenuse, see võtab aega umbes 7 ~ 15days oma käsi.
Kui pakki üle 100kg saadame kaudu DHL või lennutranspordiga. See võtab umbes 3 ~ 7days oma käsi.
Kõik pakendid on vormi Hiina Guangzhou.
* Pakett saadetakse kingitusena ja deklareeritakse nii vähe kui võimalik, ostjal pole vaja "MAKSU" eest maksta.
* Pärast laeva, saadame teile e-kirja ja teile jälgimise numbri.
|
|
|
Garantii jaoks.
Võtke meiega ühendust --- >> Tagastage toode meile --- >> Võtke vastu ja saatke uus asendaja.
Nimi: Liu Xiaoxia
Aadress: 305Fang HuiLanGe HuangPuDaDaoXi 273Hao TianHeQu Guangzhou Hiinas.
ZIP: 510620
Telefon: + 8618078869184
Palun pöörduge tagasi aadress ja kirjuta oma paypal aadressi, nime, probleemi märkus: |
|
