En els darrers anys, la creixent demanda d’adaptació multiplataforma ha conduït a l’augment de la reproducció de velocitat de bits adaptativa de mitjans de transmissió, cosa que ha obligat els desenvolupadors web i mòbils a replantejar-se la lògica de la tecnologia de vídeo. En primer lloc, els gegants van llançar els protocols HLS, HDS i Smooth Streaming per separat, ocultant tots els detalls rellevants als seus SDK dedicats. Els desenvolupadors no poden modificar lliurement la lògica del motor multimèdia del reproductor: no podeu modificar les regles de la velocitat de bits adaptativa i la mida de la memòria cau, ni tan sols la longitud dels vostres talls. És possible que aquests reproductors siguin senzills d’utilitzar, però no teniu massa opcions per personalitzar-lo i fins i tot les funcions dolentes només es poden tolerar.
Però amb l’augment de diferents escenaris d’aplicacions, la demanda de funcions personalitzables és cada vegada més forta. Entre la transmissió en directe i la demanda, hi ha diferències en la gestió de memòria intermèdia, les estratègies ABR i les estratègies de memòria cau. Aquests requisits van donar lloc a una sèrie d’APIs d’operacions multimèdia de nivell inferior: Netstream a Flash, Extensions de fonts de recursos a HTML5 i Media Codec a Android. Al mateix temps, va aparèixer a la indústria un format de transmissió estàndard basat en HTTP MPEG-DASH. . Aquestes funcions més avançades proporcionen als desenvolupadors una major flexibilitat, que els permet construir reproductors i motors multimèdia que s'adaptin a les seves necessitats empresarials.
Avui compartirem com es pot construir un reproductor modern i quins components clau es necessiten per construir-lo. En termes generals, un reproductor típic es pot dividir en tres parts: interfície d’usuari, motor multimèdia i descodificador.
Interfície d'usuari (IU): aquesta és la part més alta del reproductor. Defineix l’experiència de visualització de l’usuari final a través de tres característiques funcionals diferents: skin (disseny de l’aspecte del reproductor), interfície d’usuari (totes les funcions personalitzables com ara llistes de reproducció i intercanvi social, etc.) i lògica empresarial (lògica empresarial específica) com a publicitat, lògica de compatibilitat de dispositius i gestió de certificacions, etc.).
Motor multimèdia: gestiona tota la lògica relacionada amb el control de reproducció, com ara l’anàlisi de fitxers de descripció, la captació de clips de vídeo i la configuració i el canvi de regles de velocitat de bits adaptatives. A continuació explicarem aquesta part amb detall. Atès que aquests motors estan generalment estretament lligats a la plataforma, pot ser que sigui necessari utilitzar diversos motors diferents per cobrir totes les plataformes.
Gestor de descodificador i DRM: la part més baixa del reproductor és el descodificador i el gestor de DRM. Les funcions d'aquesta capa criden directament a les API exposades pel sistema operatiu. La funció principal del descodificador és descodificar i representar el contingut del vídeo, mentre que el gestor de DRM controla si es té dret a reproduir-lo mitjançant el procés de desxifratge.
A continuació, utilitzarem exemples per introduir els diferents rols que juga cada capa.
1. Interfície d'usuari (IU)
La capa d’interfície d’usuari és la capa superior del reproductor. Controla el que els usuaris poden veure i interactuar amb ells. Al mateix temps, podeu personalitzar-lo amb la vostra pròpia marca per oferir als usuaris una experiència d'usuari única. Aquesta capa és la més propera a la part de desenvolupament frontal de què parlem. Dins de la interfície d’usuari, també incloem components de lògica empresarial, que constitueixen la singularitat de la vostra experiència de reproducció, tot i que l’usuari final no pot interactuar directament amb aquesta part de la funció.
La part de la IU conté principalment tres components:
1) Pell
Skin és un terme general per a les parts visualment relacionades del reproductor: barres de control de progrés, botons, icones animades, etc., tal com es mostra a la figura 2. Com la majoria de components de disseny, aquesta part del component també s’implementa mitjançant CSS, que pot ser integrat fàcilment per dissenyadors o desenvolupadors (fins i tot si utilitzeu una solució completa com JW Player i Bitdash).
2) Lògica de la IU
La part lògica de la IU defineix totes les interaccions visibles durant la reproducció i la interacció de l'usuari: llistes de reproducció, miniatures, selecció de canals de reproducció i compartició de xarxes socials. En funció de l’experiència de reproducció que espereu aconseguir, es poden afegir moltes altres funcions a aquesta part en el passat, moltes de les quals existeixen en forma de connectors, i potser podeu trobar alguna inspiració: Connectors · videojs / video.js Part lògica Wiki · GitHub Hi ha moltes funcions incloses. No els introduirem en detall, però prenem com a exemple la interfície d’usuari del jugador Eurosport per experimentar intuïtivament aquestes funcions.
A més dels elements tradicionals de la IU, també hi ha una característica molt interessant. Quan l’usuari està veient el contingut multimèdia del DVR, l’emissió en directe es mostra en forma de finestra petita i el públic pot tornar a l’emissió en directe en qualsevol moment a través d’aquesta petita finestra. Com que el disseny o la interfície d’usuari i el motor multimèdia són completament independents, aquestes funcions es poden implementar utilitzant dash.js en HTML5 amb només unes poques línies de codi. Per a la part de la IU, la millor manera d'implementar-la és afegir diverses funcions als mòduls bàsics de la IU en forma de connectors / mòduls.
3) Lògica empresarial
A més de les funcions "visibles" de les dues parts anteriors, hi ha una altra part invisible que constitueix la singularitat del vostre negoci: autenticació i pagament, adquisició de canals i llistes de reproducció i publicitat. També hi ha algunes coses relacionades amb la tecnologia, com ara mòduls de prova A / B i configuracions relacionades amb el dispositiu. Aquestes configuracions s'utilitzen per seleccionar diversos motors multimèdia diferents entre diversos tipus de dispositius.
Per tal de descobrir la complexitat oculta a la part inferior, explicarem aquests mòduls amb més detall aquí:
Lògica de detecció i configuració de dispositius: aquesta és una de les funcions més importants, ja que separa la reproducció i la representació. Per exemple, en funció de les diferents versions del vostre navegador, el reproductor pot triar automàticament un motor multimèdia basat en HTML5 MSE, hls.js o un motor de reproducció basat en flash FlasHls per reproduir fluxos de vídeo HLS. La característica més important d'aquesta part és que, independentment del motor subjacent que utilitzeu, podeu utilitzar el mateix JavaScript o CSS per personalitzar la vostra interfície d'usuari o la lògica empresarial de la capa superior.
La possibilitat de detectar equips de l'usuari us permet configurar l'experiència de l'usuari final segons sigui necessari: si esteu jugant en un dispositiu mòbil en lloc d'un dispositiu de pantalla 4K, potser haureu de començar amb una taxa de bits inferior.
Lògica de prova A / B: la prova A / B consisteix en poder grisar alguns usuaris en el procés de producció. Per exemple, podeu proporcionar a alguns usuaris de Chrome un botó nou o un motor multimèdia nou, i també podeu assegurar-vos que tota la seva feina estigui funcionant tal com estava previst.
Publicitat (opcional): processar la publicitat per part del client és una de les lògiques empresarials més complexes. Tal com es mostra al diagrama de flux del mòdul de connectors videojs-contrib-ads, hi ha diversos passos en el procés d’inserció d’anuncis. Per a la transmissió de vídeo HTTP, utilitzeu més o menys alguns formats existents, com ara VAST, VPAID o Google IMA, que us poden ajudar a treure anuncis de vídeo del servidor d’anuncis (normalment formats no responsius obsolets), ubicats a principis, mitjans i les darreres etapes del vídeo per reproduir-les i no es poden ometre.
resumir:
Per a les vostres necessitats de personalització, podeu optar per utilitzar JW Player que inclogui totes les funcions clàssiques per jugar (també us permet personalitzar algunes de les funcions) o personalitzar les vostres pròpies funcions basades en un reproductor de codi obert com Videojs. Fins i tot per unificar l’experiència de l’usuari entre el navegador i el reproductor natiu, també podeu plantejar-vos utilitzar React Native per a la interfície d’usuari o el desenvolupament de la pell i Haxe per al desenvolupament de la lògica empresarial. Aquestes excel·lents biblioteques poden ser de molts tipus diferents. El mateix conjunt de bases de codi es comparteixen entre els dispositius.
2, el motor multimèdia
En els darrers anys, el motor multimèdia ha aparegut a l'arquitectura del reproductor com un nou component independent. A l'era MP4, la plataforma processava tota la lògica relacionada amb la reproducció i només algunes de les funcions relacionades amb el processament multimèdia (només funcions com la reproducció, pausa, arrossegar i deixar anar i el mode de pantalla completa) es van obrir als desenvolupadors.
No obstant això, el nou format de transmissió basat en HTTP requereix un component nou per gestionar i controlar la nova complexitat: analitzar fitxers de declaracions, descarregar clips de vídeo, supervisar la velocitat de bits adaptativa, designar la presa de decisions i molt més. Al principi, la complexitat d’ABR la gestionava la plataforma o el proveïdor d’equips. Tanmateix, amb la creixent demanda de control d’ancoratge i reproductors personalitzats, alguns reproductors nous han obert gradualment algunes API de nivell inferior (com ara Media Source Extensons al web, Netstream a Flash i Media Codec a la plataforma Android) i s’han atret ràpidament molts motors multimèdia potents i robustos basats en aquestes API subjacents.
A continuació, explicarem detalladament els detalls de cada component al modern motor de processament multimèdia:
1) Interpretació i analitzador de fitxers de declaracions
A la transmissió de vídeo basada en HTTP, tot comença amb un fitxer de descripció. El fitxer de declaració conté metainformació que el servidor multimèdia ha d’entendre: quants tipus diferents de qualitat de vídeo, idioma i lletres, etc., i quins són. L'analitzador obté la informació de descripció del fitxer XML (un fitxer m3u8 especial per a HLS) i, a continuació, obté la informació de vídeo correcta a partir de la informació. Per descomptat, hi ha molts tipus de servidors multimèdia i no tots implementen les especificacions correctament, de manera que és possible que l’analitzador hagi de fer front a alguns errors d’implementació addicionals.
Un cop extreta la informació del vídeo, l'analitzador analitzarà les dades per construir una imatge visual en streaming i saber obtenir diferents clips de vídeo. En alguns motors multimèdia, aquestes imatges visuals apareixen primer en forma d’imatge multimèdia abstracta i després dibuixen a la pantalla les diferents característiques dels diferents formats de flux de vídeo HTTP.
A l'escena de la transmissió en directe, l'analitzador també ha de tornar a adquirir periòdicament el fitxer de declaració per obtenir la informació més recent del videoclip.
2) Descarregador (descarregar fitxers de declaracions, clips i claus multimèdia)
El descarregador és un mòdul que envolta l'API nativa per processar les sol·licituds HTTP. No només s’utilitza per descarregar fitxers multimèdia, sinó que també es pot utilitzar per descarregar fitxers de declaracions i claus DRM quan sigui necessari. El descarregador té un paper molt important en la gestió d’errors i intents de xarxa, alhora que pot recopilar dades sobre l’amplada de banda disponible actualment.
Nota: La descàrrega de fitxers multimèdia pot fer servir el protocol HTTP o altres protocols, com ara el protocol WebRTC en l'escenari de comunicació punt a punt en temps real.
3) Motor de transmissió
El motor de reproducció en streaming és el mòdul central que interactua amb l'API del descodificador. Importa diferents clips multimèdia al codificador i gestiona la commutació i les diferències de diverses taxes durant la reproducció (com ara la diferència entre fitxers de declaració i talls de vídeo i congelacions automàtiques). Saltant el marc).
4) predictor de paràmetres de qualitat de recursos (amplada de banda, CPU, velocitat de trames, etc.)
L’estimador obté dades de diverses dimensions (mida del bloc, temps de descàrrega per fragment i nombre de fotogrames saltats) i les agrupa per estimar l’amplada de banda i la potència de càlcul de la CPU disponible per als usuaris. Aquesta és la sortida que s’utilitza per al controlador de commutació ABR (Adaptive Bitrate, Adaptive Bitrate), per fer judicis.
5) Controlador de commutació ABR
El commutador ABR pot ser la part més crítica del motor multimèdia, normalment la part més ignorada. El controlador llegeix les dades (amplada de banda i nombre de fotogrames saltats) que emet l’estimador, utilitza un algorisme personalitzat per fer judicis basats en aquestes dades i indica al motor de transmissió si ha de canviar la qualitat del vídeo o de l’àudio. Hi ha un munt de treballs de recerca en aquest camp i la dificultat més gran és trobar un equilibri entre el risc de reposició de la memòria intermèdia i la freqüència de commutació (un canvi massa freqüent pot conduir a una mala experiència de l'usuari).
6) Administrador de DRM (component opcional)
Avui en dia tots els serveis de vídeo de pagament es basen en la gestió de DRM, i el DRM depèn en gran mesura de la plataforma o l’equipament, veurem quan expliquem el reproductor més endavant. El gestor DRM del motor multimèdia és un embolcall per a l'API de desxifrat de contingut del descodificador de nivell inferior. Sempre que sigui possible, intentarà protegir les diferències en els detalls d’implementació de navegadors o sistemes operatius de manera abstracta. Aquest component sol estar estretament connectat amb el motor de processament de fluxos perquè sovint interactua amb la capa de descodificació.
7) Multiplexor de conversió de formats (component opcional)
Com veurem més endavant, cada plataforma té les seves limitacions quant a empaquetatge i codificació (Flash llegeix fitxers H.264 / AAC encapsulats en contenidors FLV i MSE llegeix fitxers H.264 / AAC encapsulats en contenidors ISOBMFF. Fitxer). Això condueix a alguns clips de vídeo que cal formatar abans de descodificar-los. Per exemple, amb el multiplexor de conversió de format MPEG2-TS a ISOBMFF, hls.js pot utilitzar contingut en format MSE per reproduir reproduccions de vídeo HLS. S'ha qüestionat el multiplexor de conversió de formats a nivell de motor multimèdia; no obstant això, amb la millora de la interpretació moderna de JavaScript o Flash, la pèrdua de rendiment que comporta és gairebé insignificant i no provocarà un gran impacte en l'experiència de l'usuari.
resumir
També hi ha molts components i funcions diferents al motor multimèdia, des de subtítols fins a captures de pantalla fins a la inserció d’anuncis, etc. A continuació, també escriurem un article separat per comparar les diferències entre una varietat de motors diferents, mitjançant algunes proves i dades del mercat per donar algunes orientacions substancials per a la selecció del motor. Val a dir que per construir un reproductor compatible amb diverses plataformes, és molt important proporcionar múltiples motors multimèdia lliurement substituïbles, ja que el descodificador subjacent està relacionat amb la plataforma d’usuari. A continuació, ens centrarem en aquest aspecte.
3. Descodificador i gestor de DRM
Per al rendiment de la descodificació (descodificador) i les consideracions de seguretat (DRM), el descodificador i el gestor de DRM estan estretament lligats a la plataforma del sistema operatiu.
1) Descodificador
El descodificador gestiona la lògica relacionada amb la reproducció de la capa inferior. Desempaqueta vídeos en diferents formats d’encapsulació, descodifica el seu contingut i, a continuació, lliura els marcs de vídeo descodificats al sistema operatiu per a la seva representació i, finalment, permet veure els usuaris finals.
A mesura que els algoritmes de compressió de vídeo són cada vegada més complexos, el procés de descodificació és un procés que requereix càlculs intensius i, per tal de garantir un rendiment de descodificació i una experiència de reproducció fluida, el procés de descodificació ha de dependre fortament del sistema operatiu i del maquinari. La majoria de la descodificació actual es basa en l'ajut de la descodificació accelerada de la GPU (aquesta és també una de les raons per les quals el descodificador VP9 lliure i més potent no ha guanyat la posició de mercat H.264). Si no hi ha acceleració de la GPU, la descodificació d’un vídeo 1080P ocuparà aproximadament el 70% del càlcul de la CPU i la taxa de pèrdues de fotogrames pot ser molt greu.
Basant-se en la descodificació i representació de fotogrames de vídeo, el gestor també proporciona una memòria intermèdia nativa. El motor multimèdia pot interactuar directament amb el buffer per comprendre la seva mida en temps real i actualitzar-lo quan calgui.
Com hem esmentat anteriorment, cada plataforma té el seu propi motor de renderització i l'API corresponent: la plataforma Flash té Netstream, la plataforma Android té Media Codec API i el web té extensions de fonts de mitjans estàndard. MSE és cada vegada més cridaner i pot esdevenir l’estàndard de facto en altres plataformes després del navegador en el futur.
2) Gestor de DRM
Avui en dia, el DRM és necessari per transferir contingut de pagament produït per estudis. Cal evitar que es robin aquests continguts, de manera que els usuaris i els desenvolupadors bloquegin el codi i el procés de treball de DRM. El contingut desxifrat no sortirà de la capa de descodificació, de manera que no serà interceptat.
Per tal d’estandarditzar el DRM i proporcionar certa interoperabilitat per a la implementació de diverses plataformes, diversos gegants web van crear conjuntament Common Encryption (CENC) i l’extensió de xifrat multimèdia universal Encrypted Media Extensions per proporcionar múltiples proveïdors de DRM (per exemple, EME es pot utilitzar per Playready a la plataforma Edge i Widewine a la plataforma Chrome per crear un conjunt d’APIs comunes que puguin llegir la clau de xifratge de contingut de vídeo des del mòdul d’autorització DRM per desxifrar-lo.
CENC va declarar un conjunt de mètodes de xifratge i mapatge de claus estàndard, que es poden utilitzar per desxifrar el mateix contingut en diversos sistemes DRM, només proporcionant la mateixa clau.
Dins del navegador, basat en la metainformació del contingut del vídeo, EME pot identificar quin sistema DRM s’utilitza per xifrar i trucar al mòdul de desxifrat corresponent (Content Decryption Module, CDM) per desxifrar el contingut xifrat per CENC. El mòdul de desxifrat CDM gestionarà el treball relacionat amb l'autorització de contingut, obtindrà la clau i desxifrarà el contingut del vídeo.
CENC no especifica l’emissió d’autoritzacions, el format d’autorització, l’emmagatzematge d’autoritzacions i les relacions d’assignació de permisos i regles d’ús i altres detalls. El tractament d’aquests detalls és responsabilitat del proveïdor de DRM.
4. resum
Avui coneixem profundament els diferents continguts dels tres nivells del reproductor de vídeo. La millor part d’aquesta moderna estructura de reproductors és que la seva part interactiva està completament separada de la part lògica del motor multimèdia, cosa que permet a l’àncora personalitzar l’experiència de l’usuari final de forma perfecta, lliure i flexible. , L'ús simultani de diferents motors multimèdia en diversos dispositius terminals pot assegurar la reproducció fluida de diversos formats de contingut de vídeo.
A la plataforma web, gràcies a l’ajuda de motors multimèdia com dash.js, Shaka Player i hls.js, que solen ser biblioteques madures, MSE i EME s’estan convertint en nous estàndards de reproducció i els fabricants cada vegada més influents utilitzen ells. Aquests motors de reproducció. En els darrers anys, l’atenció també s’ha començat a estendre als descodificadors i als televisors d’Internet, i també hem vist cada vegada més dispositius nous que utilitzen MSE com a motor de processament multimèdia subjacent. Continuarem invertint més esforços per donar suport a aquests estàndards.
|
|
|
|
A quina distància (llarg) de la coberta del transmissor?
L'abast de transmissió depèn de molts factors. La distància real es basa en la instal·lació de l'antena d'altura, guany d'antena, utilitzant com a mitjà de construcció i altres obstruccions, la sensibilitat del receptor, l'antena del receptor. La instal·lació de l'antena més alta i l'ús en el camp, la distància serà molt més lluny.
Transmissor FM 5W exemple, l'ús a la ciutat i la ciutat natal:
Tinc un client d'ús del transmissor FM amb antena 5W EUA GP a la seva ciutat natal, i ho prova amb un cotxe, és cobrir 10km (6.21mile).
Puc provar el transmissor de FM amb antena GP 5W a la meva ciutat natal, que cobreixen al voltant 2km (1.24mile).
Puc provar el transmissor de FM amb antena 5W metge de capçalera a la ciutat de Guangzhou, que només cobreixen al voltant 300meter (984ft).
A continuació es presenten l'interval aproximat de diferents transmissors de FM de potència. (El rang és de diàmetre)
Transmissor FM 0.1W ~ 5W: 100M ~ 1KM
5W ~ 15W FM Ttransmitter: 1KM ~ 3KM
Transmissor FM 15W ~ 80W: 3KM ~ 10KM
Transmissor FM 80W ~ 500W: 10KM ~ 30KM
Transmissor FM 500W ~ 1000W: 30KM ~ 50KM
Transmissor FM 1KW ~ 2KW: 50KM ~ 100KM
Transmissor FM 2KW ~ 5KW: 100KM ~ 150KM
Transmissor FM 5KW ~ 10KW: 150KM ~ 200KM
Com posar-se en contacte amb nosaltres per al transmissor?
Llámame + O 8618078869184
vam enviar un correu electrònic [protegit per correu electrònic]
1.How fins on vol cobrir de diàmetre?
2.How alta que la torre?
3.Where ets?
I li donarem un assessorament més professional.
Sobre Nosaltres
FMUSER.ORG és una empresa d’integració de sistemes centrada en equips de transmissió i transmissió de vídeo sense fil de radiofreqüència / estudi i processament de dades. Oferim tot, des de l'assessorament i la consultoria a través de la integració de bastidors fins a la instal·lació, la posada en servei i la formació.
Oferim transmissor FM, transmissor de televisió analògica, transmissor de televisió digital, transmissor UHF VHF, antenes, connectors de cable coaxial, STL, processament aeri, productes de difusió per a estudi, monitorització de senyals RF, codificadors RDS, processadors d’àudio i unitats de control de llocs remots, Productes IPTV, codificador / decodificador d’àudio / vídeo, dissenyats per satisfer les necessitats de grans xarxes de difusió internacionals i de petites estacions privades.
La nostra solució compta amb estació de ràdio FM / estació de televisió analògica / estació de televisió digital / equip d’estudi d’àudio i vídeo / enllaç de transmissor d’estudi / sistema de telemetría de transmissor / sistema de televisió d’hotel / transmissió en directe IPTV / transmissió en directe de transmissió / conferència de vídeo / sistema de difusió CATV.
Utilitzem productes de tecnologia avançada per a tots els sistemes, ja que sabem que l’alta fiabilitat i l’alt rendiment són tan importants per al sistema i la solució. Al mateix temps, hem d'assegurar-nos que el nostre sistema de productes té un preu molt raonable.
Tenim clients de radiodifusors públics i comercials, operadors de telecomunicacions i autoritats reguladores, i també oferim solucions i productes a molts centenars d’emissores locals, petites i comunitàries.
FMUSER.ORG porta exportant més de 15 anys i té clients a tot el món. Amb 13 anys d’experiència en aquest camp, comptem amb un equip professional per resoldre tot tipus de problemes del client. Ens dediquem a subministrar els preus extremadament raonables de productes i serveis professionals. Correu electrònic de contacte : [protegit per correu electrònic]
la nostra fàbrica
Tenim modernització de la fàbrica. Que són benvinguts a visitar la nostra fàbrica quan s'arriba a la Xina.
En l'actualitat, ja hi ha clients 1095 a tot el món van visitar la nostra oficina Guangzhou Tianhe. Si vostè ve a la Xina, que són benvinguts a visitar-nos.
a la Fira
Aquesta és la nostra participació en 2012 Global Sources Hong Kong Electronics Fair . Els clients de tot el món finalment tenir l'oportunitat de reunir-se.
On és Fmuser?
Podeu cercar aquests números " 23.127460034623816,113.33224654197693 "a google map, podreu trobar la nostra oficina fmuser.
FMUSER oficina de Guangzhou es troba al districte de Tianhe, que és el centre del Cantó . molt a prop fins al Fira de Canton , Estació de tren de Guangzhou, Xiaobei carretera i Dashatou , Només cal 10 minuts si pren TAXI . Benvinguts amics de tot el món a visitar i negociar.
Contacte: Blue Sky
Cel·lular: + 8618078869184
WhatsApp: + 8618078869184
Wechat: + 8618078869184
Adreça electrònica: [protegit per correu electrònic]
QQ: 727926717
Skype: sky198710021
Adreça: Sala de No.305 Huilan Edifici No.273 Huanpu carretera Guangzhou, Xina Codi postal: 510620
|
|
|
|
Anglès: Acceptem tots els pagaments, com PayPal, targeta de crèdit, Western Union, Alipay, Money Bookers, T / T, LC, DP, DA, OA, Payoneer, si teniu cap pregunta, poseu-vos en contacte amb mi [protegit per correu electrònic] o WhatsApp + 8618078869184
-
PayPal.  www.paypal.com
Recomanem que utilitzi PayPal per comprar els nostres articles, el PayPal és una forma segura per comprar a Internet.
Cada pàgina de la nostra llista d'elements de fons a la part superior tenen un logotip de PayPal per pagar.
Targeta de crèdit.Si no té PayPal, però vostè ha targeta de crèdit, també pot fer clic al botó groc de PayPal per pagar amb la targeta de crèdit.
-------------------------------------------------- -------------------
Però si vostè no té una targeta de crèdit i no tenir un compte de PayPal o difícil va aconseguir un accout PayPal, pot utilitzar el següent:
Unió Occidental.  www.westernunion.com
Pagar per Western Union a mi:
Nom i cognoms: Yingfeng
Cognom / Cognom / Nom de família: Zhang
Nom complet: Yingfeng Zhang
País: Xina
Ciutat: Guangzhou
|
-------------------------------------------------- -------------------
T / T. pagar amb T / T (transferència bancària / transferència telegràfica / transferència bancària)
Primera informació bancària (COMPTE DE L'EMPRESA):
SWIFT BIC: BKCHHKHHXXX
Nom del banc: BANK OF CHINA (HONG KONG) LIMITED, HONG KONG
Adreça bancària: BANC DE LA TORRE DE XINA, 1 GARDEN ROAD, CENTRAL, HONG KONG
CÓDIG BANC: 012
Nom del compte: FMUSER INTERNATIONAL GROUP LIMITED
Núm de compte. : 012-676-2-007855-0
-------------------------------------------------- -------------------
Segona informació bancària (COMPTE DE L'EMPRESA):
Beneficiari: Fmuser International Group Inc.
Número de compte: 44050158090900000337
Banc del beneficiari: sucursal del Guangdong de China Construction Bank
Codi SWIFT: PCBCCNBJGDX
Adreça: carretera NO.553 Tianhe, Guangzhou, Guangdong, districte de Tianhe, Xina
** Nota: quan transferiu diners al nostre compte bancari, NO escriviu res a l'àrea de comentaris, en cas contrari no podrem rebre el pagament a causa de la política governamental sobre comerç internacional.
|
|
|
|
* Aquest document s'enviarà a 1 2-dies de treball quan el pagament és clar.
* Enviarem a la seva adreça de PayPal. Si vostè vol canviar la direcció, si us plau, envieu la vostra direcció correcta i número de telèfon a la vostra adreça [protegit per correu electrònic]
* Si els paquets es troba per sota 2kg, ens enviaran a través de correu aeri, trigarà aproximadament 15-25days a la mà.
Si el paquet és més que 2kg, enviarem a través d'EMS, DHL, UPS, Fedex lliurament ràpid expressa, prendrà al voltant de 7 ~ 15days al seu costat.
Si el paquet de més de 100kg, anem a enviar per DHL o el noli aeri. Es durà a prop 3 ~ 7days al seu costat.
Tots els paquets són la forma xinesa de Guangzhou.
* El paquet s'enviarà com a "regal" i es descomptarà el mínim possible, perquè el comprador no hagi de pagar l'impost.
* Després de la nau, li enviarem un correu electrònic i li donarà el nombre de seguiment.
|
|
|
Per a la garantia.
Poseu-vos en contacte amb nosaltres --- >> Envieu-nos l'article --- >> Rebeu i envieu un altre substitut.
Nom: Liu xiaoxia
Direcció: 305Fang HuiLanGe HuangPuDaDaoXi 273Hao TianHeQu Guangzhou, Xina.
Postal: 510620
Telèfon: + 8618078869184
Si us plau, torni a aquesta adreça i escriure el seu PayPal, nom, adreça problema a la nota: |
|
El nostre altre producte:
