yhteinen kanta:
1: RTSP RTMP HTTP on kaikki sovelluskerroksessa.
2: Teoriassa RTSP rtmphttp: tä voidaan käyttää suorana lähetyksenä ja tarvittaessa, mutta RTSP RTMP: tä käytetään yleensä suorana lähetyksenä ja HTTP pyynnöstä. SIP-protokollaa käytettiin videoneuvotteluissa, ja nyt se on periaatteessa korvattu RTMP: llä.
ero:
Kopioi koodi
1: Http: eli hypertekstin siirtoprotokolla (FTP on tiedostonsiirtoprotokolla).
Http: (reaaliaikainen suoratoistoprotokolla), reaaliaikainen suoratoistoprotokolla.
HTTP: n koko nimen reititystaulukon ylläpitoprotokolla.
2: HTTP käsittelee kaikki tiedot tiedostoina. HTTP-protokolla ei ole suoratoistoprotokolla.
RTMP ja RTSP ovat suoratoistomediaprotokollia.
3: RTMP-protokolla on adoben yksityinen sopimus, jota ei täysin julkisteta. RTSP-protokolla ja HTTP-protokolla ovat yleisiä sopimuksia, ja niiden ylläpitoon tarvitaan erityisiä organisaatioita.
4: RTMP-protokolla lähettää yleensä flv-, f4v-muotoisen virran, RTSP-protokolla yleensä lähettää ts, MP4-muotoisen virran. HTTP: llä ei ole tiettyä streamia.
5: RTSP-lähetys vaatii yleensä 2-3 kanavaa, komento- ja datakanavien erottelun, HTTP ja RTMP yleensä siirtävät komentoja ja dataa yhdellä TCP-kanavalla.
Kopioi koodi
Erot RTSP: n, RTCP: n ja RTP: n välillä
Kopioi koodi
1: RTSP reaaliaikainen virtausprotokolla
Sovelluskerrosprotokollana RTSP tarjoaa laajennettavan kehyksen, jonka avulla voidaan hallita ja tarvittaessa suoratoistaa tietoja reaaliajassa. Yleensä RTSP on suoratoistovälineen esitysprotokolla, jota käytetään pääasiassa reaaliaikaisilla ominaisuuksilla tapahtuvan tiedonsiirron hallintaan, mutta se ei välitä itse tietoja, vaan sen on luotettava joihinkin alemman kerroksen siirtoprotokollan tarjoamiin palveluihin. RTSP voi tarjota toimintoja, kuten toisto, tauko, pikakelaus eteenpäin ja niin edelleen median suoratoistoon. Se vastaa tiettyjen ohjaussanomien, toimintatapojen, tilakoodien jne. Määrittelemisestä ja kuvaa myös vuorovaikutuksen RTP: n kanssa (rfc2326).
2: RTCP-ohjausprotokolla
RTCP-ohjausprotokollaa on käytettävä RTP-dataprotokollan kanssa. Kun sovellus käynnistää RTP-istunnon, se vie kaksi porttia samanaikaisesti, joita RTP ja RTCP käyttävät. Itse RTP ei voi tarjota luotettavaa takuuta datapakettien peräkkäiselle lähettämiselle, eikä liikenteenohjausta ja ruuhkanhallintaa, jotka kaikki ovat RTCP: n suorittamia. Yleensä RTCP käyttää samaa jakelumekanismia kuin RTP, lähettää ohjaustiedot säännöllisesti kaikille istunnon jäsenille. Sovellus voi hallita palvelun laatua tai diagnosoida verkon kunnon vastaanottamalla tietoja, hankkimalla istunnon osallistujien asiaankuuluvat tiedot, verkon tilan, pakettihäviötodennäköisyyden ja muuta palautetietoa.
RTCP-protokollan toiminta toteutetaan erilaisilla RTCP-datagrammeilla, jotka ovat pääasiassa seuraavantyyppisiä:
SR: Lähettäjäraportti viittaa sovellukseen tai päätelaitteeseen, joka lähettää RTP-dataraportin, ja lähettäjä voi olla myös vastaanottaja. (palvelimen kiinteä aika lähetetään asiakkaalle).
RR: vastaanottavat loppuraportit. Niin sanottu vastaanottopää viittaa sovellukseen tai päätelaitteeseen, joka vain vastaanottaa, mutta ei lähetä RTP-dataraportteja. (palvelin vastaanottaa asiakaspuolen lähettämän vastauksen).
SDE: lähdekuvaus, päätoiminto on toimia istunnon jäsenten tunnistetietojen, kuten käyttäjänimen, sähköpostiosoitteen, puhelinnumeron jne., Kantajana, ja sillä on myös välitysistunnon ohjausinformaatio istunnon jäsenille.
Hei: ilmoitus lähtee. Päätoiminto on osoittaa, että yksi tai useampi lähde ei ole enää voimassa, toisin sanoen muut ilmoitusistunnon jäsenet poistuvat istunnosta itse.
Sovellus: itse sovelluksen määrittelemä se ratkaisee RTCP-skaalautuvuuden ongelman ja tarjoaa paljon joustavuutta protokollan toteuttajille.
3: RTP-dataprotokolla
RTP-dataprotokolla vastaa pakettivirtausmediatiedoista ja mediavirran reaaliaikaisesta lähettämisestä. Jokainen RTP-datapaketti koostuu kahdesta osasta: pää ja kuorma. Pään ensimmäiset 12 tavua ovat kiinteät, kun taas kuorma voi olla ääni- tai videodata.
RTP: n käyttämä paikka on leikki. Palvelin käyttää UDP-protokollaa tietojen lähettämiseen asiakkaalle. RTP lisää 12 tavun otsikon (kuvaustiedot) tiedonsiirron eteen.
RTP-latauspaketin suunnittelu verkkolähetys tässä artikkelissa perustuu IP-protokollaan, joten suurin lähetysyksikkö (MTU) on 1500 tavua. IP / UDP / RTP-protokollahierarkiaa käytettäessä tämä sisältää vähintään 20 tavua IP-otsikkoa, 8 tavun UDP-otsikkoa ja 12 tavun RTP-otsikkoa. Täten otsikkotiedot vievät vähintään 40 tavua, ja RTP-kuormituksen enimmäiskoko on 1460 tavua. Otetaan esimerkkinä H264, jos kehystieto on suurempi kuin 1460, se on pakattava palasiksi, purettava sitten vastaanottimessa ja yhdistettävä sitten datakehykseen dekoodausta ja toistoa varten.
Kopioi koodi
Live-sovelluksessa RTMP ja HLS voivat periaatteessa kattaa kaiken asiakkaan katselun,
HLS: llä on pääasiassa suuri viive, ja RTMP: llä on tärkein etu matalassa viiveessä.
1 、 Sovelluskenaariot
Pienen viiveen sovelluskenaarioita ovat:
Kopioi koodi
Interaktiivinen suora lähetys: esimerkiksi suosittu kauneuden ankkuri vuonna 2013, live-peli jne
Eri isännät, suoratoistovälineet jaetaan käyttäjille katselua varten. Käyttäjät voivat keskustella tekstin kanssa ja olla vuorovaikutuksessa isännän kanssa.
Videoneuvottelu: jos kentällä on kollegoita, käytämme videoneuvottelua sisäisten kokousten pitämiseen.
Itse asiassa ei ole väliä, viivästyykö kokous yhden sekunnin ajan, koska kun joku muu on lopettanut puhumisen, muiden on ajateltava sitä,
Ajattelun aikaviive on myös noin 1 sekunti. Tietysti, jos riidelet videoneuvottelun kanssa, et voi.
. muut: seuranta ja suorat lähetykset vaativat myös viivettä joissakin paikoissa,
RTMP-protokollan viive Internetissä voi periaatteessa täyttää vaatimukset.
Kopioi koodi
2 、 RTMP ja viive
1. RTMP: n ominaisuudet ovat seuraavat:
Kopioi koodi
1) Adobe tukee hyvin:
RTMP on itse asiassa teollisuuden standardiprotokolla kooderilähdölle, periaatteessa kaikki kooderit (kamerat ja niin edelleen) tukevat RTMP-lähtöä.
Syynä on se, että PC-markkinat ovat valtavat, tietokone on pääasiassa Windows, ja Windows-selaimet tukevat periaatteessa salamaa,
Flash tukee myös RTMP: tä erittäin hyvin.
2) Sopii pitkään pelaamiseen:
Koska RTMP tukee erittäin hyvin, se voi saavuttaa flash-toiston RTMP-virtaa pitkään ja jatkuvasti,
Testi oli miljoona sekuntia tai yli 10 päivän jatkuva toisto.
Kaupallisissa suoratoistosovelluksissa asiakkaan vakaus on varmasti välttämätöntä, muuten loppukäyttäjät eivät näe kuinka pelata?
Tiesin, että oli olemassa koulutusohjelma, joka alun perin toisti HTTP-streamia pelaajien kanssa ja tarvitsi toistaa erilaisia tiedostoja, ja aina oli ongelma,
Jos palvelinpuoli muuntaa eri tiedostot RTMP-streamiksi, asiakas voi toistaa koko ajan;
Kun asiakas siirtyi RTMP-järjestelmään, hän ei kuullut, että asiakkaalla oli ongelmia CDN: n jakelun jälkeen.
3) Matala viive:
RTMP viivästyy paljon (1-3 sekuntia) kuin YY-tyyppinen UDP-yksityinen protokolla,
RTMP on pienempi kuin HTTP-virtaviive (yleensä yli 10 sekuntia).
Niin kauan kuin yleinen suoran lähetyksen sovellus ei ole sellainen puhelinkeskustelu, RTMP-viive on hyväksyttävä.
Yleisesti videoneuvottelusovelluksissa RTMP-viive on hyväksyttävä, koska kuuntelemme muita heidän puhuessaan,
Itse asiassa yhden sekunnin viiveellä ei ole merkitystä, ja meidän on ajateltava sitä (joillakin ihmisillä ei ole vielä suorittimen prosessointinopeutta niin nopeasti).
4) Kumulatiivinen viive:
Teknologian on tunnettava heikkous. RTMP: n heikkous on kumulatiivinen virhe, koska RTMP ei menetä TCP: hen perustuvia paketteja.
Joten kun verkon tila on heikko, palvelin välimuisti paketit, mikä johtaa kumulatiiviseen viiveeseen;
Kun verkko on hyvässä kunnossa, lähetä se asiakkaalle yhdessä.
Ratkaisu on katkaista yhteys uudelleen, kun asiakaspuskuri on suuri.
Kopioi koodi
2. HLS: n matala viive
Jotkut ihmiset kysyvät aina tämän kysymyksen, kuinka vähentää HLS-viivettä.
HLS ratkaisee viiveen, aivan kuten kiipeäminen vaahterapuun kalojen saamiseksi. Outoa, että yhä on ihmisiä, jotka huutavat, katso, on kaloja.
Mitä sanot?
Voin vain sanoa, että osallistut vaatimattomuuden, illuusioiden taikaesitykseen.
Jos olet todella varma, näytä se todellisen mittauskuvan kanssa, katso alla viivästynyt mittaus.
3. RTMP-viiveen mittaus
Viiveen mittaaminen on vaikea ongelma,
On kuitenkin tehokas tapa käyttää matkapuhelimen sekuntikelloa, joka voi verrata viivettä tarkemmin.
Todetaan, että kun verkko on hyvässä kunnossa, löydetään seuraavat toimenpiteet:
Kopioi koodi
. RTMP-viive voi olla noin 0.8 sekuntia.
. monitasoinen reunasolmu ei vaikuta viiveeseen (SRS: n kanssa homologisen CDN: n reunapalvelin voi tehdä sen)
. nginx RTMP -viive on vähän suuri. Arvioidaan, että välimuistinkäsittely johtuu moniprosessiviestinnästä?
. GOP on vaikea indikaattori, mutta SRS voi sammuttaa GOP: n välimuistin tämän vaikutuksen välttämiseksi
. palvelimen suorituskyky on liian heikko, mikä myös aiheuttaa viiveen kasvamisen, eikä palvelin voi lähettää tietoja.
. asiakkaan puskurin pituus vaikuttaa myös viiveeseen.
Esimerkiksi flash-asiakas NetStream.bufferTime Aseta 10 sekuntiin ja viivytä sitten vähintään 10 sekuntia.
Kopioi koodi
4. GOP-välimuisti
Mikä on GOP? Onko videovirran kahden I-kehyksen välinen aikaetäisyys.
Mikä on GOP: n vaikutus?
Flash (dekooderi) voi aloittaa dekoodauksen ja toiston vain, kunnes se saa GOP: n.
Toisin sanoen palvelin antaa ensin flashille I-kehyksen.
Valitettavasti ongelma on, oletetaan, että GOP on 10 sekuntia, ts. Joka 10 sekunti on avainkehyksiä,
Entä jos käyttäjä alkaa pelata viidennessä sekunnissa?
Ensimmäinen ratkaisu: odota seuraavaa kehystä I,
Toisin sanoen, odota vielä 5 sekuntia aloittaaksesi asiakastietojen antamisen.
Tämä viive on hyvin pieni, aina reaaliaikainen virta.
Ongelma on: odottavat 5 sekuntia ovat mustia. Ilmiö on, että pelaaja on jumissa siellä, ei mitään,
Jotkut käyttäjät saattavat ajatella olevansa kuolleita ja päivittävät sivun.
Lyhyesti sanottuna jotkut asiakkaat ajattelevat, että avainkehysten odottaminen on anteeksiantamaton virhe. Mikä on viiveiden suhde?
Haluan vain aloittaa ja toistaa videota nopeasti, ja avaan sen paremmin ja toistan sen!
Toinen ratkaisu: aloita nyt,
Mitä laitat?
Sinun täytyy tietää. Laita edellinen I-kehys.
Toisin sanoen palvelimen on aina tallennettava välimuisti GOP,
Joten asiakas toistaa edellisen I-kehyksen ja aloittaa nopeasti.
Ongelma on: viivästykset ovat luonnollisesti suuria.
Onko olemassa hyvää suunnitelmaa?
Joo! On olemassa vähintään kahta tyyppiä:
Kooderi laskee GOP: n, kuten 0.5 sekuntia, GOP: n, joten viive on pieni eikä tarvitse odottaa.
Haittana on, että kooderin pakkaussuhde pienenee, eikä kuvanlaatu ole niin hyvä.
5. kumulatiivinen viive
GOP-välimuistin lisäksi on suhde, kumulatiivinen viive.
Palvelin voi määrittää live-jonon pituuden, ja palvelin laittaa tiedot live-jonoon,
Jos ylität tämän pituuden, tyhjennä viimeiseen I-kehykseen asti:
Tätä ei tietenkään voi määrittää liian pieneksi,
Esimerkiksi GOP on yksi sekunti, jonon_ pituus on yksi sekunti, mikä aiheuttaa tietojen tyhjentämisen 1 sekunnissa ja hyppää.
On parempi tapa? kyllä meillä on.
Viive on periaatteessa yhtä suuri kuin asiakkaan puskuripituus. Koska viive johtuu pääasiassa pienestä verkon kaistanleveydestä, palvelin lähettää sen asiakkaalle yhdessä välimuistin tallentamisen jälkeen. Ilmiö on, että asiakkaan puskuri on suurempi,
esimerkiksi NetStream.BufferLength = 5 sekuntia, sitten puskurissa on vähintään 5 sekuntia tietoa.
Paras tapa käsitellä kumulatiivista viivettä on, että asiakas havaitsee, että puskurissa on paljon dataa, ja jos se pystyy, kytke palvelin uudelleen.
Tietenkin, jos verkko on ollut huono, ei ole mitään keinoa.
|
|
|
|
Kuinka pitkälle (pitkä) lähettimen kansi?
Kantamaa riippuu monista tekijöistä. Todellinen etäisyys, joka perustuu antennin asennuksen korkeus, antennin vahvistus, käyttäen ympäristön, kuten rakennus ja muita esteitä, vastaanottimen herkkyyttä, antenni vastaanottimen. Asentaminen antenni enemmän korkean ja käyttämällä maaseudulla, etäisyyttä tulee huomattavasti pidemmälle.
Esimerkki 5W FM-lähetin käyttää kaupungin ja kotikaupunki:
Olen USA asiakaskäyttöön 5W fm lähetin GP antenni kotikaupungissaan ja hän testata sen autoa, se kattaa 10km (6.21mile).
Testaan 5W fm lähetin GP antenni kotikaupungissani, se kattaa noin 2km (1.24mile).
Testaan 5W fm lähetin GP antennin Guangzhou, se kattaa noin vain 300meter (984ft).
Alla on likimäärin välillä eri vallan FM-lähetin. (Valikoima on halkaisija)
0.1W ~ 5W FM-lähetin: 100M ~ 1KM
5W ~ 15W FM Ttransmitter: 1KM ~ 3KM
15W ~ 80W FM-lähetin: 3KM ~ 10KM
80W ~ 500W FM-lähetin: 10KM ~ 30KM
500W ~ 1000W FM-lähetin: 30KM ~ 50KM
1KW ~ 2KW FM-lähetin: 50KM ~ 100KM
2KW ~ 5KW FM-lähetin: 100KM ~ 150KM
5KW ~ 10KW FM-lähetin: 150KM ~ 200KM
Miten yhteyttä lähettimen?
Soita minulle + 8618078869184 TAI
Lähetä minulle [sähköposti suojattu]
1.How pitkälle haluat kattaa halkaisijaltaan?
2.How pitkä teistä torni?
3.Where olet kotoisin?
Ja me annamme sinulle enemmän ammatillisia neuvoja.
Tietoa Meistä
FMUSER.ORG on RF-langattomaan siirtoon / studio-video-äänilaitteisiin / streaming- ja tietojenkäsittelyyn keskittyvä järjestelmäintegraatioyritys. Tarjoamme kaikkea neuvonnasta ja konsultoinnista telineiden integroinnin ja asennuksen, käyttöönoton ja koulutuksen kautta.
Tarjoamme FM-lähetintä, analogista TV-lähetintä, digitaalista TV-lähetintä, VHF-UHF-lähetintä, antenneja, koaksiaalikaapeliliittimiä, STL-laitteita, ilmankäsittelyä, lähetystuotteita studioon, RF-signaalin seurantaa, RDS-enkoodereita, ääniprosessoreita ja etäsivuston ohjausyksiköitä IPTV-tuotteet, Video / Audio Encoder / Decoder, jotka on suunniteltu vastaamaan sekä suurten kansainvälisten lähetysverkkojen että pienten yksityisten asemien tarpeisiin.
Ratkaisumme sisältää FM-radioaseman / analogisen TV-aseman / digitaalisen TV-aseman / audio-video-studiolaitteet / studiolähettimen linkin / lähettimen telemetriajärjestelmän / hotellin TV-järjestelmän / IPTV-suoralähetyksen / suoratoiston suorana lähetyksenä / videoneuvottelun / CATV-lähetysjärjestelmän.
Käytämme kehittyneitä teknologiatuotteita kaikkiin järjestelmiin, koska tiedämme, että korkea luotettavuus ja korkea suorituskyky ovat niin tärkeitä järjestelmän ja ratkaisun kannalta. Samalla meidän on myös varmistettava, että tuotteemme ovat erittäin kohtuulliset.
Meillä on asiakkaita julkisissa ja kaupallisissa yleisradioyhtiöissä, teleoperaattoreissa ja sääntelyviranomaisissa, ja tarjoamme myös ratkaisuja ja tuotteita monille satoja pienemmille, paikallisille ja yhteisön yleisradioyhtiöille.
FMUSER.ORG on vienyt yli 15 vuotta ja sillä on asiakkaita ympäri maailmaa. Meillä on 13 vuoden kokemus tällä alalla, ja meillä on ammattitaitoinen tiimi ratkaisemaan asiakkaan kaikenlaisia ongelmia. Olemme sitoutuneet toimittamaan ammattitaitoisten tuotteiden ja palveluiden erittäin kohtuullisen hinnoittelun. Sähköpostiosoite: [sähköposti suojattu]
Tehtaamme
Meillä on modernisointi tehtaasta. Tervetuloa käymään tehtaalla, kun tulla Kiinaan.
Tällä hetkellä on jo olemassa 1095 asiakkaita ympäri maailmaa vierailivat Guangzhou Tianhe toimistoon. Jos tulet Kiinaan, olet tervetullut käymään.
Fair
Tämä on meidän osallistuminen 2012 Global Sources Hongkong Electronics Fair . Asiakkaita ympäri maailmaa Lopuksi on mahdollisuus saada yhdessä.
Missä on Fmuser?
Voit etsiä näistä numeroista " 23.127460034623816,113.33224654197693 "Google-kartasta löydät fmuser-toimistomme.
FMUSER Guangzhou toimisto on Tianhen joka on keskellä Canton . Erittäin lähellä että Canton Fair , guangzhou rautatieasema, Xiaobei tie- ja dashatou , Tarvitsee vain 10 minuuttia jos kestää TAKSI . Tervetuloa ystäviä ympäri maailmaa käymään ja neuvotella.
Yhteydenotto: Sky Blue
Fax: + 8618078869184
WhatsApp: + 8618078869184
Wechat: + 8618078869184
Sähköposti: [sähköposti suojattu]
QQ: 727926717
Skype: sky198710021
Osoite: No.305 Room Huilan Building No.273 Huanpu Road Guangzhou Kiina Postinumero: 510620
|
|
|
|
Englanti: Hyväksymme kaikki maksut, kuten PayPal, Luottokortti, Western Union, Alipay, Money Bookers, T / T, LC, DP, DA, OA, Payoneer. Jos sinulla on kysyttävää, ota minuun yhteyttä [sähköposti suojattu] tai WhatsApp + 8618078869184
-
PayPal.  www.paypal.com
Suosittelemme käyttämään Paypal ostaa meidän kohteita, The Paypal on turvallinen tapa ostaa internetissä.
Jokainen meidän Tuoteluettelosi sivu pohja päälle ole PayPal logo maksaa.
Luottokortti.Jos sinulla ei ole paypal, mutta teillä on luottokortti, voit myös napsauttamalla Keltainen PayPal-painiketta maksaa luottokortilla.
-------------------------------------------------- -------------------
Mutta jos et ole luottokorttia, eikä ole PayPal-tili tai vaikeasti sai paypal accout, voidaan käyttää seuraavia:
Western Union.  www.westernunion.com
Maksa Western Union minulle:
Etunimi / etunimi: Yingfeng
Sukunimi / sukunimi / sukunimi: Zhang
Koko nimi: Yingfeng Zhang
Maa: Kiina
Kaupunki: Guangzhou
|
-------------------------------------------------- -------------------
T / T. Maksa T / T (tilisiirto / lennätin siirto / pankkisiirto)
Ensimmäiset pankkitiedot (YRITYSTILI):
SWIFT BIC: BKCHHKHHXXX
Pankin nimi: BANK OF CHINA (HONG KONG) LIMITED, HONG KONG
Pankkiosoite: BANK OF CHINA TOWER, 1 PUUTARHA, CENTRAL, HONG KONG
Pankkikoodi: 012
Tilin nimi: FMUSER INTERNATIONAL GROUP LIMITED
Tilinumero NO. : 012-676-2-007855-0
-------------------------------------------------- -------------------
Toiset pankkitiedot (YRITYSTILI):
Edunsaaja: Fmuser International Group Inc.
Tilinumero: 44050158090900000337
Edunsaajan pankki: China Construction Bank Guangdong Branch
SWIFT-koodi: PCBCCNBJGDX
Osoite: NO.553 Tianhe Road, Guangzhou, Guangdong, Tianhen alue, Kiina
** Huomaa: Kun siirrät rahaa pankkitilillemme, ÄLÄ kirjoita mitään huomautusalueelle, muuten emme voi vastaanottaa maksua hallituksen kansainvälisen kaupan liiketoimintaa koskevan politiikan vuoksi.
|
|
|
|
* Se lähetetään 1-2 työpäivää kun maksu selvä.
* Me lähettää sen paypal osoite. Jos haluat muuttaa osoitetta, lähetä oikea osoite ja puhelinnumero sähköpostiini [sähköposti suojattu]
* Jos puolat on alle 2kg, me lähetetään postitse lentoposti, kestää noin 15-25days käteen.
Jos paketti on enemmän kuin 2kg, lähetämme kautta EMS, DHL, UPS, Fedex nopea express toimitus kestää noin 7 ~ 15days käteen.
Jos paketti enemmän kuin 100kg, lähetämme kautta DHL tai lentorahtina. Se kestää noin 3 ~ 7days käteen.
Kaikki paketit ovat muotoa Kiina Guangzhou.
* Paketti lähetetään "lahjana" ja ilmoitetaan mahdollisimman vähän, ostajan ei tarvitse maksaa "VEROSTA".
* Kun laiva, lähetämme sinulle sähköpostin ja antaa sinulle seurantanumeron.
|
|
|
Takuuta varten.
Ota yhteyttä meihin --- >> palauta tuote meille --- >> Vastaanota ja lähetä uusi korvaava tuote.
Nimi: Liu Xiaoxia
Osoite: 305Fang HuiLanGe HuangPuDaDaoXi 273Hao TianHeQu Guangzhoussa Kiinassa.
ZIP: 510620
Puhelin: + 8618078869184
Palauta tähän osoitteeseen ja kirjoita paypal osoite, nimi, ongelma huomautus: |
|
Meidän muiden tuotteiden:
