Sammendrag: med den raske utviklingen av bredbånd i kablede og trådløse nettverk, er folk ikke lenger fornøyde med den enkle informasjonen som ord og bilder på Internett, men flere og flere ønsker å se mer intuitive og fyldige film- og TV-programmer. Derfor dukker det opp medie-nettsteder. Denne artikkelen utdyper utviklingen av streaming media nettsted fra aspektene av streaming media konsept, streaming media format, streaming media file produksjon, streaming media file transmission, streaming media file publishing og streaming media website distribusjon.
Stikkord: utvikling og distribusjonsteknologi på nettstedet for streaming av medier
1. Oversikt
Det er to måter å overføre multimedia på nettverket, som er nedlasting og streaming. Hvis filoverføring betraktes som en prosess, vil ikke nedlastings- og overføringsmodus brukes før filoverføringen er fullført. Ventetiden påvirkes av overføringshastigheten og mottakerens kapasitet; Streaming brukes under sending. Streaming medieteknologi gjør det mulig for den første mock-eksamenen å kunne lytte til TV-programmene på Internett uten å vente på lang nedlastingstid. Denne modusen er veldig lik tradisjonell kringkasting og TV-kringkasting, og betyr også innvirkningen av internettmediene på tradisjonelle kringkastings- og TV-medier. Utviklingen av streaming media nettsted er basert på streaming media teknologi, som kombinerer streaming media filer med websider for å spille av streaming media filer via websider.
2. Konseptet med streaming medieteknologi
Streaming er en overføringsteknologi som overfører lyd- og videoinformasjon til en fast hastighet uavhengig av nettverksbelastning mellom avsender og mottaker. Streaming media har karakteristikkene av implisitt tidsdimensjon, sanntidsoverføring og høy gjennomstrømning. Streaming medieteknologi er en teknologi som bruker streaming for å overføre kontinuerlige tidsbaserte medier. Streaming-modus er å komprimere video, lyd og andre medier til komprimeringspakker, og streaming-serveren overfører dem til brukere i sanntid. Klienten kan begynne å spille ved å cache nok videopakker til å spille.
3. Vanlige streamingfilformater
Formatet for streaming av mediefiler som brukes i nettverket er veldig forskjellig fra dataprogrammene. For eksempel kan MPEG-1, som VCD-standard, brukes til SIF-standardoppløsning (352 for NTSC-system) × 240, 352 for PAL × 288) av bildet er komprimert, og overføringshastigheten er 1.5 Mbps. Men denne hastigheten er vanskelig for nettverksbrukere å oppnå. Så den populære streamingmedieteknologien er en teknologi som tar sikte på internettets lave båndbredde og overføringskvalitet. Den publiserer hovedsakelig multimediafilformatet etter "sekundær" behandling. Det inkluderer anskaffelse, koding, overføring, lagring og dekoding. Systemet for streaming av medieapplikasjoner er generelt delt inn i tre deler: kodingsende, serverside og klient. Forskjellig fra utviklingen av Internett-teknologi, er utviklingen av streaming mediesystem fremdeles i produsentens standardfase.
4. Streaming medieoverføringsteknologi
I applikasjonen av lagringslyd- og videodatastrøm, ber klienten om komprimerte lyd- og videofiler som er lagret på serveren. Denne serveren kan være en vanlig webserver eller en streaming medieserver dedikert til å tilby tjenester for lyd- og videostreaming. Serveren sender lyd- og videofiler til en kontakt som er koblet til klienten. Både TCP- og UDP-kontakter kan oppnå denne funksjonen. Før du sender filer til nettverket, blir filene segmentert og innkapslet med spesielle overskrifter som passer til filoverføringen. Realtidsprotokoll (RTP) er en vanlig domenestandard som innkapsler segmentene ovenfor. Når klienten begynner å motta de forespurte lyd- og videofilene, vil den begynne å spille om noen sekunder. Interaksjonsfunksjonen fullføres med pause, fortsett og hopp av spilletid.
Brukere ber om lyd- og videostreaming via nettleser, men fordi avspillingen ikke er integrert i klienten, krever det et sekundært program for å spille av filer - mediespillere, for eksempel ekte spiller av ekte nettverk og Windows Media Player fra Microsoft. Mediaspilleren har følgende funksjoner:
(1) Komprimering, for å spare lagringsplass og nettverksbåndbredde, komprimeres vanligvis lyd og video. Mediaspilleren må dekomprimeres mens du spiller.
(2) Fjern jittergrupper. Jitter er forskjellen i forsinkelsen av pakker fra kilde til destinasjon i datastrømmen. Siden lyd og video må spilles samtidig, må mottakeren cache de mottatte pakkene i kort tid for å eliminere jitter.
(3) Feilretting. På grunn av uforutsigbar overbelastning på Internett kan et segment av pakkedatastrømmen gå tapt. Hvis klippet er veldig stort, vil ikke brukerne kunne akseptere kvaliteten på lyd og video. Mange streaming-systemer prøver å gjenopprette tapte data. De rekonstruerer enten tapte pakker gjennom overføring av overflødige pakker, eller ber direkte om at pakkene overføres på nytt, eller de utleder og setter inn de tapte dataene fra de mottatte dataene.
(4) Brukergrensesnitt med kontrolldeler. Dette er brukerens operasjonelle del, inkludert volumkontroll, pause / fortsett-knapper, tidshoppglidebryter, etc.
Lyd- og videofiler lagres på webserveren og sendes til klienten via HTTP, eller sendes til klienten via ikke HTTP på streaming-serveren.
Driftsprosessen til dette systemet er som følger:
(1) Nettleseren oppretter en TCP-forbindelse til webserveren og sender HTTP-forespørselsmeldingen som ber om lyd- og videofiler.
(2) Webserveren sender en HTTP-svarmelding med lyd- og videofiler til nettleseren.
(3) Innholdstypeoverskriftslinjen i HTTP-svarmeldingen erklærer den angitte lyd- og videokodingen. Klientens nettleser analyserer innholdstypen i svarmeldingen, ringer til den aktuelle mediaspilleren og sender filen til mediaspilleren.
(4) Mediaspilleren begynner å spille av filen.
Problemet med denne typen mediespill er at mediespilleren må samhandle med serveren gjennom nettleseren. Dette krever at hele filen må lastes ned helt før den kan sendes til mediaspilleren for avspilling. For større filer er forsinkelsen før avspilling vanskelig å akseptere. Av denne grunn må en slik applikasjon vedta en direkte kontaktforbindelse mellom serveren og mediespillerprosessen, som er direkte fra serveren til mediaspilleren.
Metafiler er filer som gir streaming av lyd- og videofilinformasjon (for eksempel URL, kodingstype). Webserveren sender lyd / video direkte til mediaspilleren. Etableringsprosessen for denne direkte TCP-forbindelsen er som følger:
(1) Brukeren klikker på lyd- / videofilhyperkoblingen.
(2) Denne lenken er ikke direkte til en lyd- / videofil, men en metafil. Denne metafilen inkluderer URL-en til den faktiske lyd- / videofilen. Svarmeldingen innkapsler denne metafilen, inkludert overskriftslinjen av innholdstypen, og erklærer den angitte lyd- / videofilen.
(3) Klientens nettleser analyserer overskriftslinjen for innholdstypen i svarmeldingen, ringer til den aktuelle mediaspilleren og overfører hele rapportstilen til svarmeldingen til mediaspilleren.
(4) Mediaspilleren oppretter en TCP-forbindelse direkte til HTTP-serveren. Mediaspilleren sender en HTTP-melding som ber om lyd- / videofiler til TCP-tilkoblingen.
(5) Filen sendes til mediaspilleren via HTTP-svarmelding, og mediespilleren begynner å streame.
Det mellomliggende trinnet for å få metafiler er veldig viktig. Når nettleseren vet innholdstypen til filen, kan den ringe den aktuelle mediaspilleren, og deretter kommuniserer mediespilleren direkte med serveren.
Begge de to ovennevnte arkitekturene til mediaspillere passerer HTTP, slik at de kommuniserer med serveren gjennom TCP. HTTP kan ikke fullt ut forstå samspillet mellom brukere og servere, spesielt er det ikke lett for brukere (gjennom medieserveren) å sende pause, fortsette, hurtigspole kommandoer til serveren.
For å unngå HTTP og TCP kan streaming-servere brukes til å overføre lyd og video til mediaspillere. Streaming server er vanligvis produsentens standard streaming server, for eksempel helix server og windows media server. Gjennom streaming-server kan applikasjonslagsprotokollen brukes til å sende lyd og video over UDP. Applikasjonslagsprotokollen er mer egnet for lyd- og videostream enn http.
Denne arkitekturen krever to servere, den ene er HTTP-server, som administrerer websider (inkludert metafiler); Den andre er streaming-server, som administrerer lyd- og videofiler. To servere kan kjøres i ett endesystem eller to uavhengige sluttsystemer. Arbeidsprosedyren er lik den forrige. Men her ber mediaspiller om data fra streaming-server i stedet for webserver. Mediaspiller og strømmeserver kan samhandle med sin egen protokoll. Disse protokollene kan lette brukerinteraksjon med lyd- og videostrømmer.
5. Publisering av strømmende medieinformasjon på nettstedet
De grunnleggende trinnene for streaming av filinformasjon er som følger:
(1) Produksjon av kildefiler, vanligvis opptak av lyd- og videoprogrammer med kameraer.
(2) Innholdet overføres til datamaskinen, og det digitale formatet registreres av bildet.
(3) Videoredigeringsprogramvaren brukes til å redigere bildeinnholdet, med undertekster eller bakgrunnsmusikk.
(4) Konverter videofiler. For å oppfylle de forskjellige brukernes behov, må vi transformere de redigerte videofilene til forskjellige formater for streaming av mediefiler. For eksempel konverteres MPEG-format til RM-format.
(5) Konfigurer nødvendig klient- og serverprogramvare for å lette utgivelsen av videodata. Forskjellige streaming-filer må konfigureres med forskjellige klienter for avspilling.
I mange nettverksapplikasjoner er ekte system mer populært. RM-filen er kjernen i ekte streaming media, helix-produsenten er nøkkelprogramvaren i ekte streaming media-produksjonsprosess. Streaming mediefiler generert av helix-produsenten plasseres i innholdskatalogen til helix-serveren, som kan realiseres etter behov. Hvis den blir kodet og sendt til helix-serveren umiddelbart, kan direktesendingsfunksjonen realiseres. I tillegg kan spiralprodusenten konvertere andre formater av multimediafiler til ekte streamingfiler.
Helix-produsent plus9 kan konvertere andre multimediafiler til ekte streamingmedier, live lyd og video til ekte streamingmedier, og kan også sendes til helix-serveren for direktesending samtidig med kodingen.
Ø 【Lydmodus] inkluderer tre moduser: musikk, stemme og ingen lyd, som hovedsakelig brukes til å stille inn effekten av lyd. For blandet lyd eller lyd på høyt nivå er "musikk" -modusen bedre.
Ø 【Videomodus inkluderer "standard bevegelsesvideo", "high-key image", "smooth motion", "slide display" og "no video" -modus. Når det er mange filmer i videoen, bør modusen "standard film" velges; Hvis du vil ha en høy definisjon, kan du velge "high key image"; Hvis du vil at overgangen til bildet skal bli jevnere, kan du velge jevn bevegelsesmodus; For å bytte effekt av stillbildeproduksjon kan bare høyoppløselig opprettholdes. På dette tidspunktet kan "lysbildefremvisning" -modus velges.
Ø 【Videokoder] inkluderer tre typer kodere: realvideo G2 med SVT, realvideo 8 og realvideo 9. I hvilken som helst bithastighet kan realvideo 9-koding oppnå den beste videoeffekten.
Ø 【SureStream-funksjon i publikumsvalget] -kolonnen kan overføre det samme lyd- og videoinnholdet i flere forskjellige hastigheter. De er integrert i en streaming mediefil, som vil sende tilsvarende innhold spontant i henhold til nettverkshastigheten til målgruppen.
Koblingen fra nettsiden til ekte streamingmedier er ikke direkte koblet til RM-filen, men gjennom ram-filen. Hvis ekte streamingmedier er innebygd i websiden, blir det realisert av RPM-fil.
Når brukere klikker på en lenke til en streamingfil på den virkelige serveren, vil mange nettlesere ikke starte RealPlayer som en sekundær spiller på grunn av deres opprinnelige innstillinger. Real-system gir en mellomfil (RAM-fil) for å hjelpe klientsystemet med å starte RealPlayer.
Ram-filen er en ren tekstfil, og filtypen er.Ram. I ram-filen viser URL-adressen til streaming-filen du vil spille. Når brukerleseren laster inn ram-fil, startes RealPlayer som sekundær spiller. RealPlayer overføres automatisk i mediefilen i henhold til URL-adressen i RAM-filen for avspilling.
Når du skriver en webside, aktiveres det virkelige streamingmediet av ram-filen ved å koble til ram-filen på helix-serveren eller webserveren gjennom standardlenken. For eksempel:
Ram.htm-filen er
<title> link ram file
og test.rpm Dokumentene er:
http://127.0.0.1/realvideo.rm
Kjør med nettleseren rpm.htm File, RealPlayer-spilleren blir innebygd i nettlesersiden.
6. Distribusjon av nettstedet for streaming av media
Strømmemediesystemet til hver produsent har sine egne egenskaper, men hovedkomponentene er fire deler: mediekoder, mediefilminne, medieserver og mediaspiller. De fire delene samarbeider om å danne streamingtjenestesystemet. Systemarkitekturen og forholdet er vist i figur 4
Ø Mediekoder. De originale mediefilene eller sanntidsmediedataene som samles inn av kameraet, gjøres til et filformat (streamformat) som er egnet for nettverksoverføring, og deretter lagres streamingfilene i mediefilminnet eller sendes direkte til streamingmedieserveren .
Ø Mediefilminne. Mediefilene i formatet for lagringsstrøm er vanligvis SCSI-harddisk eller diskmatrise.
Ø Medieserver. Som svar på brukerforespørselen overført fra webserveren av planleggingsserveren, overføres streamingfilen til brukerens skrivebord gjennom nettverksoverføringsprotokollen.
Ø Mediaspiller. Motta nettverksmediedata og spill den lokalt.
For lastbalansering og støtte for flere brukere, bygger medieserver generelt en LAN-klynge og utfører NBP-bildebehandling. En administrasjonsserver sender brukerforespørsler til serveren med den laveste belastningen i henhold til lasttilstanden til hver server. Ledelsesserveren er også ansvarlig for streaming av mediefiladministrasjon, digital opphavsretthåndtering, etc. Portalsiden til streamingtjenester er fortsatt en webserver.
7. Kvalitetskontroll av streaming mediaoverføring
Kvalitetskontroll for overføring er den viktigste faktoren som begrenser ytelsen til streamingtjenestetjenester, og er også den viktigste bekymringen for streamingmedieoperatører. Det vil si, under den eksisterende nettverksbåndbredden, hvordan man støtter så mange samtidige som mulig og hvordan man kan garantere end-to-end streaming media QoS.
For å støtte så mange samtidige brukere som mulig, og unngå økning i serverbelastning og QoS-reduksjon på grunn av et stort antall samtidige tall, kreves det at systemet styrer og begrenser nettverkstrafikken og det samtidige antallet.
Forholdet mellom de tre ovennevnte indikatorene skal oppfylle følgende krav: maksimal nettbåndbredde / maksimalt samtidighetstall ≤ maksimal enkeltstrømhastighet. Metodene for å bestemme ovennevnte indekser er forskjellige for forskjellige produsenters streamingmedieprodukter. Noen er satt direkte på serversiden; Noen er satt gjennom lisensmekanismen, men de faktiske verdiene er fortsatt relatert til serverytelsen.
Streaming mediatjeneste er en slags bredbåndstjeneste, som har høye krav til nettverksbåndbredde, jitter, forsinkelse og pakketapstakt. For å gi bedre QoS har flere modne båndbreddetilpasningsteknologier og kvalitetskontrollteknologier blitt utviklet innen streaming av media.
Ø Intelligent flytteknologi. Systemet kan automatisk oppdage nettverkstilstanden og justere attributtene til lyd- og videostrøm til det beste, slik at brukerne kan motta mediestrømmen som tilsvarer tilkoblingshastigheten, for å oppnå den beste brukeropplevelsen. Essensen av denne artikkelen er å oppdage endring av nettverksbåndbredde gjennom hastighetsfeedbackmekanismen for applikasjonslaget av c / s-modellen, og justere overføringshastigheten til mediestrøm dynamisk på serversiden ved å bruke medias multihastighets hierarkiske kodingsevne. strøm for å sikre at brukerne fremdeles kan motta mediestrøm av bedre kvalitet under forutsetning av endring av nettverksbåndbredde.
Ø Split-teknologi. Den brukes vanligvis i direktesending på Internett. Den sendende serveren sender direktemediestrømmen til flere mottakerservere distribuert over hele verden ved hjelp av UDP unicast og multicast. Klienten kan få tilgang til serveren i nærheten for å oppnå mediestrøm av høy kvalitet og redusere bruken av båndbredde. Det er to moduser for trykk og trekk inn teknologien til shunt.
Ø Innholdsdistribusjon nettverksteknologi (CDN). Som et innholdsoverleggsnettverk på grunnlag av IP-nettverk, ved å innføre aktiv innholdsadministrasjon, global belastningsbalansering og innholdsbuffer, kan den publisere det streamingmedieinnholdet som brukerne ber om, til nærmeste nettverkskant for brukeren, for å forbedre brukerens få tilgang til svarhastighet, effektivt løse overbelastning i nettverket og minimere trafikken til ryggradenettverket.
Ø Caching. Fordi Internett er basert på diskontinuerlig asynkron pakkeoverføring, vil en sanntids mediestrøm eller mediefil bli delt inn i flere pakker for overføring. På grunn av nettverksforsinkelse, jitter og andre faktorer, kan rekkefølgen og forsinkelsen på pakken som kommer til klienten være forskjellig, og tilfellet med å sende pakker før ankomst kan forekomme. Derfor er cache-systemet nødvendig for å kompensere for innflytelsen av nettverksforsinkelse og jitter for å sikre riktig sekvens av datapakker og fenomenet avspilling av pause på grunn av midlertidig overbelastning i nettverket. Cache-teknologien inkluderer fremoverbuffer, omvendt hurtigbuffer og gjennomsiktig proxy-hurtigbufferteknologi
|
|
|
|
Hvor langt (lang) senderen dekke?
Rekkevidden avhenger av mange faktorer. Den virkelige avstand er basert på antennen installeres høyde, antenneforsterkning, ved hjelp miljø som bygning og andre hindringer, følsomheten til mottakeren, antennen til mottakeren. Installere antennen mer høy og bruke på landsbygda, avstanden vil mye mer langt.
Eksempel 5W FM-sender bruke i byen og hjemby:
Jeg har en USA kundens bruk 5W FM-sender med GP-antenne i hjembyen, og han teste den med en bil, det dekker 10km (6.21mile).
Jeg teste 5W FM-sender med GP-antenne i hjembyen min, det dekker ca 2km (1.24mile).
Jeg teste 5W FM-sender med GP-antenne i byen Guangzhou, det dekker omtrent bare 300meter (984ft).
Nedenfor er det tilnærmede område av forskjellige kraft FM-sendere. (Utvalget er diameter)
0.1W ~ 5W FM-sender: 100M ~ 1KM
5W ~ 15W FM Ttransmitter: 1KM ~ 3KM
15W ~ 80W FM-sender: 3KM ~ 10KM
80W ~ 500W FM-sender: 10KM ~ 30KM
500W ~ 1000W FM-sender: 30KM ~ 50KM
1KW ~ 2KW FM-sender: 50KM ~ 100KM
2KW ~ 5KW FM-sender: 100KM ~ 150KM
5KW ~ 10KW FM-sender: 150KM ~ 200KM
Hvordan kontakte oss for senderen?
Ring meg + 8618078869184 ELLER
Email meg [e-postbeskyttet]
1.How langt du ønsker å dekke i diameter?
2.How høyt av dere Tower?
3.Where er du fra?
Og vi vil gi deg mer faglige råd.
Om Oss
FMUSER.ORG er et systemintegrasjonsfirma som fokuserer på RF trådløs overføring / studio video lydutstyr / streaming og databehandling. Vi leverer alt fra råd og rådgivning gjennom rackintegrasjon til installasjon, igangkjøring og opplæring.
Vi tilbyr FM-sender, Analog TV-sender, Digital-TV-sender, VHF UHF-sender, Antenner, Koaksialkabelkontakter, STL, On Air-behandling, Broadcast-produkter for Studio, RF Signal Monitoring, RDS-kodere, Lydprosessorer og Remote Site Control Units, IPTV-produkter, Video / Audio Encoder / dekoder, designet for å møte behovene til både store internasjonale kringkastingsnettverk og små private stasjoner.
Vår løsning har FM-radiostasjon / Analog TV-stasjon / Digital TV-stasjon / Audio Video Studio-utstyr / Studio Transmitter Link / Transmitter Telemetry System / Hotel TV System / IPTV Live Broadcasting / Streaming Live Broadcast / Video Conference / CATV Broadcasting system.
Vi bruker avanserte teknologiprodukter til alle systemene, fordi vi vet at høy pålitelighet og høy ytelse er så viktige for systemet og løsningen. Samtidig må vi også sørge for at vårt produktsystem har en svært rimelig pris.
Vi har kunder fra offentlige og kommersielle kringkastingstjenester, telekomoperatører og reguleringsmyndigheter, og vi tilbyr også løsninger og produkter til mange hundre mindre, lokale og lokale kringkastere.
FMUSER.ORG har eksportert mer enn 15 år og har kunder over hele verden. Med 13 års erfaring innen dette feltet har vi et profesjonelt team for å løse kundens alle slags problemer. Vi er dedikert til å levere den ekstremt rimelige prisen på profesjonelle produkter og tjenester. Kontakt Epost : [e-postbeskyttet]
vår fabrikk
Vi har modernisering av fabrikken. Du er velkommen til å besøke vår fabrikk når du kommer til Kina.
I dag er det allerede 1095 kunder hele verden besøkt våre Guangzhou Tianhe kontor. Hvis du kommer til Kina, er du velkommen til å besøke oss.
på Fair
Dette er vår deltakelse i 2012 Global Sources Hong Kong Electronics Fair . Kunder fra hele verden endelig har en sjanse til å komme sammen.
Hvor er Fmuser?
Du kan søke i disse tallene " 23.127460034623816,113.33224654197693 "på google map, så finner du vårt fmuser-kontor.
FMUSER Guangzhou Kontoret ligger i Tianhe District, som er den midten av Canton . Veldig nær til Canton Fair , Guangzhou jernbanestasjon, Xiaobei veien og dashatou , Trenger bare 10 minutter hvis ta TAXI . Velkommen venner over hele verden til å besøke og forhandle.
Kontakt: Sky Blå
Mobil: + 8618078869184
WhatsApp: + 8618078869184
Wechat: + 8618078869184
E-post: [e-postbeskyttet]
QQ: 727926717
Skype: sky198710021
Adresse: No.305 Room Huilan Building No.273 Huanpu Road Guangzhou Kina Postnummer: 510620
|
|
|
|
Engelsk: Vi aksepterer alle betalinger, for eksempel PayPal, kredittkort, Western Union, Alipay, Money Bookers, T / T, LC, DP, DA, OA, Payoneer. Hvis du har spørsmål, kan du kontakte meg [e-postbeskyttet] eller WhatsApp + 8618078869184
-
PayPal.  www.paypal.com
Vi anbefaler at du bruker Paypal til å kjøpe våre produkter, er The Paypal en sikker måte å kjøpe på internett.
Hver av våre element liste siden bunnen på toppen har en paypal logo for å betale.
Kredittkort.Hvis du ikke har paypal, men du har kredittkort, kan du også klikke Yellow PayPal knappen for å betale med kredittkort.
-------------------------------------------------- -------------------
Men hvis du ikke har et kredittkort og ikke har en PayPal-konto eller vanskelig å fikk en paypal Kontoinnstillinger, kan du bruke følgende:
Western Union.  www.westernunion.com
Betal med Western Union til meg:
Fornavn / Fornavn: Yingfeng
Etternavn / etternavn / etternavn: Zhang
Fullt navn: Yingfeng Zhang
Land: Kina
By: Guangzhou
|
-------------------------------------------------- -------------------
T / T. betal med T / T (wire transfer / telegrafisk overføring / Bank Transfer)
Første BANKINFORMASJON (SELSKAPSKONTO):
SWIFT BIC: BKCHHKHHXXX
Bank navn: BANK OF CHINA (HONG KONG) LIMITED, HONG KONG
Bankadresse: BANKEN AV KINA TOREN, 1 GARDEN ROAD, CENTRAL, HONG KONG
BANK KODE: 012
Kontonavn: FMUSER INTERNATIONAL GROUP LIMITED
Kontonr. : 012-676-2-007855-0
-------------------------------------------------- -------------------
Andre BANKINFORMASJON (SELSKAPSKONTO):
Mottaker: Fmuser International Group Inc.
Kontonummer: 44050158090900000337
Mottakerens bank: China Construction Bank Guangdong Branch
SWIFT-kode: PCBCCNBJGDX
Adresse: NO.553 Tianhe Road, Guangzhou, Guangdong, Tianhe District, Kina
** Merk: Når du overfører penger til bankkontoen vår, vennligst IKKE skriv noe i kommentarområdet, ellers vil vi ikke kunne motta betalingen på grunn av myndighetens policy for internasjonal handel.
|
|
|
|
* Det vil bli sendt i 1-2 arbeidsdager når betaling klart.
* Vi vil sende den til din paypal adresse. Hvis du ønsker å endre adresse, send riktig adresse og telefonnummer til min e-post [e-postbeskyttet]
* Hvis pakkene er under 2kg, vil vi bli sendt via post luftpost, vil det ta ca 15-25days til hånden din.
Hvis pakken er mer enn 2kg, vil vi sende via EMS, DHL, UPS, Fedex rask ekspresslevering, vil det ta ca 7 ~ 15days til hånden din.
Hvis pakken mer enn 100kg, vil vi sende via DHL eller flyfrakt. Det vil ta om 3 ~ 7days til hånden din.
Alle pakkene er skjema Kina Guangzhou.
* Pakken sendes som en "gave" og avvises så lite som mulig, kjøper trenger ikke betale for "TAX".
* Etter skip, vil vi sende deg en e-post og gi deg sporingsnummeret.
|
|
|
For garanti.
Kontakt oss --- >> Returner varen til oss --- >> Motta og send en ny erstatning.
Navn: Liu Xiaoxia
Adresse: 305Fang HuiLanGe HuangPuDaDaoXi 273Hao TianHeQu Guangzhou Kina.
ZIP: 510620
Telefon: + 8618078869184
Vennligst gå tilbake til denne adressen og skriv din paypal adresse, navn, problem på merknad: |
|
