tir cyffredin:
1: Mae RTSP RTMP HTTP i gyd ar haen y cais.
2: Mewn theori, gellir defnyddio rtmphttp RTSP ar gyfer darllediad byw ac ar alw, ond yn gyffredinol defnyddir RTSP RTMP ar gyfer darllediad byw a HTTP ar alw. Defnyddiwyd protocol SIP mewn cynhadledd fideo, a nawr mae'n cael ei ddisodli yn y bôn gan RTMP.
gwahaniaeth:
Cod copi
1: Http: hynny yw, protocol trosglwyddo hyperdestun (protocol trosglwyddo ffeiliau yw FTP).
Http: (protocol ffrydio amser real), protocol ffrydio amser real.
Protocol cynnal a chadw bwrdd llwybro enw llawn HTTP.
2: Mae HTTP yn prosesu'r holl ddata fel ffeiliau. Nid yw'r protocol HTTP yn brotocol ffrydio.
Mae RTMP a RTSP yn ffrydio protocolau cyfryngau.
3: Mae protocol RTMP yn gytundeb preifat o adobe, nad yw'n cael ei ddatgelu'n llawn. Mae protocol RTSP a phrotocol HTTP yn gytundebau cyffredin ac mae ganddyn nhw sefydliadau arbennig i'w cynnal.
4: Yn gyffredinol, mae protocol RTMP yn trosglwyddo flv, ffrwd fformat f4v, mae protocol RTSP yn gyffredinol yn trosglwyddo ts, ffrwd fformat MP4. Nid oes gan HTTP ffrwd benodol.
5: Yn gyffredinol, mae trosglwyddiad RTSP yn gofyn am 2-3 sianel, gwahanu gorchymyn a sianel ddata, yn gyffredinol mae HTTP a RTMP yn trosglwyddo gorchmynion a data ar un sianel o TCP.
Cod copi
Gwahaniaethau rhwng RTSP, RTCP a CTRh
Cod copi
1: Protocol llif amser real RTSP
Fel protocol haen ymgeisio, mae RTSP yn darparu fframwaith estynadwy, sy'n ei gwneud hi'n bosibl rheoli ac ar alw data ffrydio mewn amser real. Yn gyffredinol, protocol cynrychiolaeth cyfryngau ffrydio yw RTSP, a ddefnyddir yn bennaf i reoli trosglwyddiad data â nodweddion amser real, ond nid yw'n trosglwyddo data ei hun, ond rhaid iddo ddibynnu ar rai gwasanaethau a ddarperir gan y protocol cludo haen is. Gall RTSP ddarparu gweithrediadau fel chwarae yn ôl, saib, yn gyflym ymlaen ac ati ar gyfer cyfryngau ffrydio. Mae'n gyfrifol am ddiffinio negeseuon rheoli penodol, dulliau gweithredu, codau statws, ac ati, ac mae hefyd yn disgrifio'r rhyngweithio â'r CTRh (rfc2326).
2: Protocol rheoli RTCP
Mae angen defnyddio protocol rheoli RTCP gyda phrotocol data CTRh. Pan fydd cais yn cychwyn sesiwn CTRh, bydd yn meddiannu dau borthladd ar yr un pryd, a ddefnyddir gan y CTRh a RTCP yn y drefn honno. Ni all y CTRh ei hun ddarparu gwarant ddibynadwy ar gyfer trosglwyddo pecynnau data yn ddilyniannol, na darparu rheolaeth traffig a rheolaeth tagfeydd, sydd i gyd wedi'u cwblhau gan RTCP. Yn gyffredinol, bydd RTCP yn defnyddio'r un mecanwaith dosbarthu â CTRh, yn anfon gwybodaeth reoli at holl aelodau'r sesiwn o bryd i'w gilydd. Gall y cymhwysiad reoli ansawdd y gwasanaeth neu wneud diagnosis o gyflwr y rhwydwaith trwy dderbyn y data, cael gwybodaeth berthnasol cyfranogwyr y sesiwn, yn ogystal â statws y rhwydwaith, tebygolrwydd colli pecyn a gwybodaeth adborth arall.
Mae swyddogaeth protocol RTCP yn cael ei wireddu gan wahanol datagramau RTCP, sydd o'r mathau canlynol yn bennaf:
SR: mae'r adroddiad anfonwr yn cyfeirio at y cais neu'r derfynell sy'n anfon adroddiad data CTRh, a gall yr anfonwr hefyd fod yn dderbynnydd. (anfon amser penodol y gweinydd i'r cleient).
RR: yr adroddiadau diwedd sy'n derbyn. Mae'r diwedd derbyn fel y'i gelwir yn cyfeirio at y cais neu'r derfynell sydd ond yn derbyn adroddiadau data CTRh ond nad ydynt yn eu hanfon. (gweinydd yn derbyn yr ymateb a anfonwyd gan ochr y cleient).
SDEs: disgrifiad o'r ffynhonnell, y brif swyddogaeth yw gwasanaethu fel cludwr gwybodaeth adnabod aelodau'r sesiwn, fel enw defnyddiwr, cyfeiriad e-bost, rhif ffôn, ac ati, ac mae ganddo hefyd y swyddogaeth o gyfleu gwybodaeth reoli sesiwn i aelodau'r sesiwn.
Hwyl: hysbysiad yn gadael. Y brif swyddogaeth yw nodi nad yw un neu fwy o ffynonellau yn ddilys mwyach, hynny yw, bydd aelodau eraill yn y sesiwn hysbysu yn gadael y sesiwn eu hunain.
Ap: wedi'i ddiffinio gan y cais ei hun, mae'n datrys problem scalability RTCP ac yn darparu llawer o hyblygrwydd i weithredwyr y protocol.
3: Protocol data CTRh
Mae protocol data CTRh yn gyfrifol am ddata cyfryngau ffrydio pecynnau a throsglwyddo llif cyfryngau mewn amser real. Mae pob pecyn data CTRh yn cynnwys dwy ran: pen a llwyth. Mae 12 beit cyntaf y pen yn sefydlog, tra gall y llwyth fod yn ddata sain neu fideo.
Y lle a ddefnyddir gan y CTRh yw chwarae. Mae'r gweinydd yn defnyddio protocol CDU i drosglwyddo data i'r cleient. Mae CTRh yn ychwanegu pennawd 12 beit (gwybodaeth ddisgrifio) i flaen y trosglwyddiad data.
Dyluniad pecyn llwyth y CTRh mae trosglwyddiad y rhwydwaith yn y papur hwn yn seiliedig ar brotocol IP, felly yr uned drosglwyddo uchaf (MTU) yw 1500 beit. Wrth ddefnyddio hierarchaeth protocol IP / CDU / CTRh, mae hyn yn cynnwys o leiaf 20 beit o bennawd IP, pennawd 8-beit CDU a phennawd 12 CTR beit. Felly, mae'r wybodaeth pennawd yn cymryd o leiaf 40 beit, a maint mwyaf llwyth y CTRh yw 1460 beit. Cymerwch H264 fel enghraifft, os yw data ffrâm yn fwy na 1460, mae angen ei bacio mewn darnau, yna ei ddadbacio yn y derbynnydd, ac yna ei gyfuno'n ffrâm o ddata ar gyfer datgodio ac ail-chwarae.
Cod copi
Mewn cymhwysiad byw, gall RTMP a HLS gwmpasu'r holl gleientiaid sy'n gwylio, yn y bôn
Mae HLS yn bennaf gydag oedi mawr, a RTMP sydd â'r brif fantais mewn oedi isel.
1 scenarios Senarios cais
Mae senarios cais oedi isel yn cynnwys:
Cod copi
Darllediad byw rhyngweithiol: er enghraifft, yr angor harddwch poblogaidd yn 2013, y gêm fyw, ac ati
Mae gwesteion amrywiol, cyfryngau ffrydio yn cael eu dosbarthu i ddefnyddwyr i'w gwylio. Gall defnyddwyr sgwrsio â thestun a rhyngweithio â'r gwesteiwr.
Cynhadledd fideo: os oes gennym gydweithwyr yn teithio yn y maes, byddwn yn defnyddio cynhadledd fideo i gynnal cyfarfodydd mewnol.
Mewn gwirionedd, nid oes ots a yw'r cyfarfod yn cael ei ohirio am eiliad, oherwydd ar ôl i rywun arall orffen siarad, mae angen i eraill feddwl amdano,
Bydd oedi amser meddwl hefyd oddeutu 1 eiliad. Wrth gwrs, os ydych chi'n ffraeo â chynhadledd fideo, allwch chi ddim.
. eraill: mae monitro a darlledu byw hefyd yn gofyn am oedi mewn rhai lleoedd,
Yn y bôn, gall oedi protocol RTMP ar y Rhyngrwyd fodloni'r gofynion.
Cod copi
2 、 RTMP ac oedi
1. mae nodweddion RTMP fel a ganlyn:
Cod copi
1) Mae Adobe yn cefnogi'n dda:
RTMP mewn gwirionedd yw'r protocol safon diwydiannol ar gyfer allbwn amgodiwr, yn y bôn mae pob amgodiwr (camerâu ac ati) yn cefnogi allbwn RTMP.
Y rheswm yw bod y farchnad PC yn enfawr, ffenestri yw'r PC yn bennaf, ac yn y bôn mae porwyr ffenestri'n cefnogi fflach,
Mae Flash hefyd yn cefnogi RTMP yn dda iawn.
2) Yn addas ar gyfer chwarae hir:
Oherwydd bod RTMP yn cefnogi'n dda iawn, gall gyflawni fflach chwarae RTMP ffrwd am amser hir ac yn barhaus,
Roedd y prawf yn filiwn eiliad, neu'n fwy na 10 diwrnod o chwarae parhaus.
Ar gyfer cymwysiadau cyfryngau ffrydio masnachol, mae sefydlogrwydd y cleient yn sicr yn angenrheidiol, fel arall, ni all defnyddwyr terfynol weld sut i chwarae?
Roeddwn i'n gwybod bod yna gleient addysg a oedd yn chwarae ffrydiau HTTP gyda chwaraewyr i ddechrau, ac angen chwarae gwahanol ffeiliau, ac roedd problem bob amser,
Os yw ochr y gweinydd yn trosi gwahanol ffeiliau yn ffrwd RTMP, gall y cleient chwarae trwy'r amser;
Ar ôl i'r cleient fynd i gynllun RTMP, ni chlywodd fod gan y cleient broblem ar ôl cael ei ddosbarthu gan CDN.
3) Oedi isel:
Mae llawer o oedi (1-3 eiliad) ar RTMP na'r math YY o brotocol preifat y CDU,
Mae RTMP yn is na'r oedi llif HTTP (mwy na 10 eiliad yn gyffredinol).
Cyn belled nad yw'r cais darlledu byw cyffredinol y math o sgwrs ffôn, mae oedi RTMP yn dderbyniol.
Mewn cymwysiadau fideo-gynadledda cyffredinol, mae hwyrni RTMP yn dderbyniol oherwydd ein bod yn gwrando ar eraill pan fyddant yn siarad,
Mewn gwirionedd, nid oes ots am un eiliad, ac mae'n rhaid i ni feddwl amdano (nid oes gan rai pobl gyflymder prosesu CPU mor gyflym eto).
4) Oedi cronnus:
Rhaid i'r dechnoleg wybod y gwendid. Gwall cronnus yw gwendid RTMP, oherwydd nid yw RTMP yn colli pecynnau ar sail TCP.
Felly pan fydd cyflwr y rhwydwaith yn wael, bydd y gweinydd yn storio'r pecynnau, sy'n arwain at yr oedi cronnus;
Pan fydd y rhwydwaith mewn cyflwr da, anfonwch ef at y cleient gyda'i gilydd.
Yr ateb yw datgysylltu'r ailgysylltiad pan fydd y byffer cleient yn fawr.
Cod copi
2. HLS oedi isel
Mae rhai pobl bob amser yn gofyn y cwestiwn hwn, sut i leihau oedi HLS.
Mae HLS yn datrys yr oedi, yn union fel dringo i'r goeden masarn i ddal pysgod. Yn rhyfedd iawn, mae yna bobl yn gweiddi o hyd, edrychwch, mae pysgod.
Beth wyt ti'n dweud?
Ni allaf ond dweud eich bod yn cymryd rhan yn y sioe hud o wyleidd-dra, rhith.
Os ydych chi'n wirioneddol siŵr, dangoswch ef gyda'r llun mesur gwirioneddol, cyfeiriwch at y mesuriad a ohiriwyd isod.
3. mesur oedi RTMP
Mae sut i fesur yr oedi yn broblem anodd,
Ond mae ffordd effeithiol o ddefnyddio stopwats y ffôn symudol, a all gymharu'r oedi yn fwy cywir.
Canfyddir, pan fydd y rhwydwaith mewn cyflwr da, y darganfyddir y mesurau a ganlyn:
Cod copi
. Gall oedi RTMP fod tua 0.8 eiliad.
. nid yw'r nod ymyl aml-lefel yn effeithio ar yr oedi (gall gweinydd ymyl CDN homologaidd ag SRS ei wneud)
. mae oedi ngMP RTMP ychydig yn fawr. Amcangyfrifir bod prosesu storfa yn cael ei achosi gan gyfathrebu aml-broses?
. Mae GOP yn ddangosydd caled, ond gall SRS ddiffodd storfa GOP er mwyn osgoi'r effaith hon
. mae perfformiad y gweinydd yn rhy isel, a fydd hefyd yn achosi i'r oedi ddod yn fwy, ac ni all y gweinydd anfon data.
. mae hyd byffer y cleient hefyd yn effeithio ar hwyrni.
Er enghraifft, fflach cleient NetStream.bufferTime Gosod i 10 eiliad, yna oedi am o leiaf 10 eiliad.
Cod copi
4. GOP-Cache
Beth yw GOP? A yw'r pellter amser rhwng y ddwy ffrâm I yn y llif fideo.
Beth yw effaith GOP?
Dim ond nes iddo gael GOP y gall fflach (datgodiwr) ddechrau datgodio a chwarae nes iddo gael GOP.
Hynny yw, mae'r gweinydd fel arfer yn rhoi ffrâm I i fflach yn gyntaf.
Yn anffodus, y broblem yw, mae'n debyg bod GOP yn 10 eiliad, hynny yw, bob 10 eiliad mae yna keyframes,
Beth os yw'r defnyddiwr yn dechrau chwarae yn y bumed eiliad?
Yr ateb cyntaf: aros am y ffrâm nesaf I,
Hynny yw, arhoswch 5 eiliad arall i ddechrau rhoi data i'r cleient.
Mae'r oedi hwn yn isel iawn, llif amser real bob amser.
Y broblem yw: bydd y 5 eiliad sy'n aros yn ddu. Y ffenomen yw bod y chwaraewr yn sownd yno, dim byd,
Efallai y bydd rhai defnyddwyr yn meddwl eu bod wedi marw ac yn adnewyddu'r dudalen.
Yn fyr, bydd rhai cwsmeriaid o'r farn bod aros am keyframes yn wall anfaddeuol. Beth yw'r berthynas rhwng oedi?
Dwi eisiau dechrau a chwarae fideo yn gyflym, a byddai'n well gen i ei agor a'i chwarae!
Yr ail ateb: dechreuwch nawr,
Beth ydych chi'n ei roi?
Rhaid i chi wybod. Rhowch y ffrâm I flaenorol.
Hynny yw, mae angen i'r gweinydd storfa GOP bob amser,
Felly bydd y cleient yn chwarae'r ffrâm flaenorol I ac yn cychwyn yn gyflym.
Y broblem yw: mae'r oedi'n naturiol fawr.
A oes cynllun da?
ie! Mae o leiaf ddau fath:
Mae'r amgodiwr yn gostwng GOP, fel 0.5 eiliad, GOP, felly mae'r oedi'n isel ac nid oes angen aros.
Yr anfantais yw y bydd cyfradd gywasgu'r amgodiwr yn cael ei ostwng, ac nid yw ansawdd y ddelwedd cystal.
5. oedi cronnus
Yn ogystal â storfa GOP, mae perthynas, hwyrni cronnus.
Gall y gweinydd ffurfweddu hyd y ciw byw, a bydd y gweinydd yn rhoi'r data yn y ciw byw,
Os ydych chi'n mynd y tu hwnt i'r hyd hwn, yn glir i'r ffrâm olaf I:
Wrth gwrs, ni ellir ffurfweddu hyn yn rhy fach,
Mae GOP, er enghraifft, yn un eiliad, ciw_ Mae hyd yn un eiliad, a fydd yn achosi i ddata gael ei glirio mewn 1 eiliad a neidio.
Mae yna ffordd well? oes, mae gennym ni.
Mae oedi yn y bôn yn hafal i hyd byffer y cleient. Oherwydd bod yr oedi yn bennaf oherwydd lled band rhwydwaith isel, bydd y gweinydd yn ei anfon at y cleient gyda'i gilydd ar ôl caching. Y ffenomen yw bod byffer y cleient yn fwy,
er enghraifft NetStream.BufferLength = 5 Ail, yna mae o leiaf 5 eiliad o ddata yn y byffer.
Y ffordd orau i ddelio â hwyrni cronnus yw bod y cleient yn canfod bod gan y byffer lawer o ddata, ac os gall, ailgysylltu'r gweinydd.
Wrth gwrs, os yw'r rhwydwaith wedi bod yn ddrwg, nid oes unrhyw ffordd.
|
|
|
|
Pa mor bell (hir) y clawr trosglwyddydd?
Mae'r ystod trosglwyddo yn dibynnu ar nifer o ffactorau. Mae'r pellter gwir yn seiliedig ar yr antena osod uchder, ennill antena, gan ddefnyddio amgylchedd fel adeiladu a rhwystrau eraill, sensitifrwydd y derbynnydd, antena y derbynnydd. Gosod antena yn fwy uchel ac yn defnyddio yn y cefn gwlad, bydd y pellter llawer mwy yn hyn.
ENGHRAIFFT 5W FM Trosglwyddydd defnyddio yn y ddinas a'r dref enedigol:
Mae gen i UDA ddefnydd cwsmeriaid 5W trosglwyddydd fm gyda antena meddygon teulu yn ei dref enedigol, ac efe brofi 'i ag a car, ei gwmpasu 10km (6.21mile).
Rwy'n profi trosglwyddydd fm 5W gyda antena meddygon teulu yn fy nhref enedigol, mae'n cynnwys tua 2km (1.24mile).
Rwy'n profi trosglwyddydd fm 5W gyda antena meddygon teulu yn ninas Guangzhou, mae'n cynnwys tua unig 300meter (984ft).
Isod mae yr ystod fras o wahanol Trosglwyddydd pŵer FM. (Mae'r ystod yn diamedr)
0.1W ~ 5W FM Trosglwyddydd: 100M ~ 1KM
5W ~ 15W FM Ttransmitter: 1KM ~ 3KM
15W ~ 80W FM Trosglwyddydd: 3KM ~ 10KM
80W ~ 500W FM Trosglwyddydd: 10KM ~ 30KM
500W ~ 1000W FM Trosglwyddydd: 30KM ~ 50KM
1KW ~ 2KW FM Trosglwyddydd: 50KM ~ 100KM
2KW ~ 5KW FM Trosglwyddydd: 100KM ~ 150KM
5KW ~ 10KW FM Trosglwyddydd: 150KM ~ 200KM
Sut i gysylltu â ni am y trosglwyddydd?
Ffoniwch fi + 8618078869184 NEU
e-bost ataf [e-bost wedi'i warchod]
1.How bell ydych am i dalu mewn diamedr?
2.How tal ohonoch tŵr?
3.Where rydych yn dod?
A byddwn yn rhoi cyngor mwy proffesiynol i chi.
Amdanom ni
Mae FMUSER.ORG yn gwmni integreiddio'r system sy'n canolbwyntio ar offer sain / ffrydio fideo / llifo di-wifr RF a phrosesu data. Rydym yn darparu popeth o gyngor ac ymgynghoriaeth trwy integreiddio rac i osod, comisiynu a hyfforddi.
Rydym yn cynnig trosglwyddydd FM, trosglwyddydd teledu analog, trosglwyddydd teledu digidol, trosglwyddydd VHF UHF, antenâu, cysylltwyr ceblau cyfechelog, STL, ar brosesu aer, cynhyrchion darlledu ar gyfer y stiwdio, monitro arwyddol RF, offerynnau RDS, proseswyr sain ac unedau rheoli safleoedd o bell, Cynhyrchion IPTV, Fideo / Encoder Sain / Sain, wedi'u cynllunio i ddiwallu anghenion rhwydweithiau darlledu rhyngwladol mawr a gorsafoedd preifat bach fel ei gilydd.
Mae gan ein datrysiad Orsaf Radio FM / Gorsaf Deledu Analog / Gorsaf Deledu Ddigidol / Offer Stiwdio Fideo Sain / Cyswllt Trosglwyddydd Stiwdio / System Telemetreg Trosglwyddydd / System Deledu Gwesty / Darlledu Byw IPTV / Ffrydio Darlledu Byw / Cynhadledd Fideo / system Ddarlledu CATV.
Rydym yn defnyddio cynhyrchion technoleg uwch ar gyfer yr holl systemau, oherwydd gwyddom fod dibynadwyedd uchel a pherfformiad uchel mor bwysig i'r system a'r datrysiad. Ar yr un pryd mae'n rhaid i ni sicrhau hefyd bod ein system cynnyrch yn bris rhesymol iawn.
Mae gennym gwsmeriaid darlledwyr cyhoeddus a masnachol, gweithredwyr telathrebu ac awdurdodau rheoleiddio, ac rydym hefyd yn cynnig atebion a chynhyrchion i gannoedd o ddarlledwyr llai, lleol a chymunedol.
Mae FMUSER.ORG wedi bod yn allforio mwy na 15 blynedd ac mae ganddo gleientiaid ledled y byd. Gyda 13 mlynedd o brofiad yn y maes hwn, mae gennym dîm proffesiynol i ddatrys pob math o broblemau cwsmer. Gwnaethom ymrwymo i gyflenwi prisiau rhesymol iawn cynhyrchion a gwasanaethau proffesiynol. E-bost cyswllt: [e-bost wedi'i warchod]
Mae ein Ffatri
Rydym wedi moderneiddio y ffatri. Mae croeso i chi ymweld â'n ffatri pan fyddwch yn dod i Tsieina i chi.
Ar hyn o bryd, mae yna eisoes cwsmeriaid 1095 o gwmpas y byd ymweld â'n swyddfa Guangzhou Tianhe. Os byddwch yn dod i Tsieina, mae croeso i chi ymweld â ni chi.
yn Ffair
Mae hyn yn ein cyfranogiad yn 2012 Ffynonellau Global Hong Kong Electronics Ffair . Cwsmeriaid o bob cwr o'r byd yn olaf yn cael cyfle i ddod at ei gilydd.
Ble mae Fmuser?
Gallwch chwilio'r rhifau hyn " 23.127460034623816,113.33224654197693 "yn google map, yna gallwch ddod o hyd i'n swyddfa fmuser.
swyddfa FMUSER Guangzhou yn Tianhe District sef y nghanol y Treganna . iawn ger i'r Ffair Treganna , gorsaf reilffordd Guangzhou, ffordd xiaobei a dashatou , Dim ond angen 10 munud os cymryd TACSI . Croeso ffrindiau o amgylch y byd i ymweld a thrafod.
Cyswllt: Sky Blue
Cellphone: + 8618078869184
WhatsApp: + 8618078869184
Wechat: + 8618078869184
E-bost: [e-bost wedi'i warchod]
QQ: 727926717
Skype: sky198710021
Cyfeiriad: Ystafell No.305 HuiLan Adeilad No.273 Road Huanpu Guangzhou Tsieina Zip: 510620
|
|
|
|
Saesneg: Rydym yn derbyn pob taliad, fel PayPal, Cerdyn Credyd, Western Union, Alipay, Archebwyr Arian, T / T, LC, DP, DA, OA, Payoneer, Os oes gennych unrhyw gwestiwn, cysylltwch â mi [e-bost wedi'i warchod] neu WhatsApp + 8618078869184
-
PayPal.  www.paypal.com
Rydym yn argymell eich bod yn defnyddio Paypal i brynu ein eitemau, The Paypal yn ffordd ddiogel i'w prynu ar y rhyngrwyd.
Mae pob un o'n dudalen rhestr eitem gwaelod ar ben cael logo paypal i dalu.
Cerdyn credyd.Os nad oes gennych paypal, ond mae gennych gerdyn credyd, gallwch hefyd glicio ar y botwm Melyn PayPal i dalu gyda'ch cerdyn credyd.
-------------------------------------------------- -------------------
Ond os nad ydych wedi gerdyn credyd ac nid gennych gyfrif PayPal neu anodd ei got a accout paypal, Gallwch ddefnyddio'r canlynol:
Undeb gorllewinol.  www.westernunion.com
Talu drwy Western Union i mi:
Enw cyntaf / Enw rhybudd: Yingfeng
Enw / Cyfenw / Enw teulu: Zhang
Enw llawn: Yingfeng Zhang
Gwlad: Tsieina
City: Guangzhou
|
-------------------------------------------------- -------------------
T / T. dalu drwy T / T (trosglwyddo gwifren / Trosglwyddo telegraffig / Trosglwyddiad Banc)
GWYBODAETH BANC Gyntaf (CYFRIF CWMNI):
SWIFT BIC: BKCHHKHHXXX
Enw'r banc: BANK OF CHINA (HONG KONG) CYFYNGEDIG, HONG KONG
Cyfeiriad y Banc: BANK OF CHINA TOWER, 1 GARDEN ROAD, CENTRAL, HONG KONG
COD BANC: 012
Enw'r Cyfrif: FMUSER INTERNATIONAL GROUP LIMITED
Nifer y Cyfrif. : 012-676-2-007855-0
-------------------------------------------------- -------------------
Ail WYBODAETH BANC (CYFRIF CWMNI):
Buddiolwr: Fmuser International Group Inc.
Rhif y Cyfrif: 44050158090900000337
Banc y Buddiolwr: Cangen Guangdong Banc Adeiladu Tsieina
Cod SWIFT: PCBCCNBJGDX
Cyfeiriad: RHIF.553 Tianhe Road, Guangzhou, Guangdong, Tianhe District, China
** Sylwch: Pan drosglwyddwch arian i'n cyfrif banc, PEIDIWCH ag ysgrifennu unrhyw beth yn yr ardal sylwadau, fel arall ni fyddwn yn gallu derbyn y taliad oherwydd polisi'r llywodraeth ar fusnes masnach ryngwladol.
|
|
|
|
* Bydd yn cael ei anfon yn 1-2 diwrnod gwaith pan fydd y taliad clir.
* Byddwn yn anfon at eich cyfeiriad paypal. Os ydych am newid cyfeiriad, anfonwch eich cyfeiriad cywir a rhif ffôn i fy e-bost [e-bost wedi'i warchod]
* Os yw'r pecynnau yn is 2kg, byddwn yn cael ei gludo drwy'r post gynwys post airmail, bydd yn cymryd tua 15-25days i eich llaw.
Os yw'r pecyn yn fwy na 2kg, byddwn yn llong drwy EMS, DHL, UPS, FedEx dosbarthu cyflym gyflym, bydd yn cymryd tua 7 ~ 15days i eich llaw.
Os bydd y pecyn yn fwy na 100kg, byddwn yn anfon drwy DHL neu cludo nwyddau awyr. Bydd yn cymryd tua 3 ~ 7days i eich llaw.
Mae pob un o'r pecynnau yn cael eu ffurflen Tsieina Guangzhou.
* Bydd pecyn yn cael ei anfon fel "rhodd" ac yn declear cyn lleied â phosib, nid oes angen i'r prynwr dalu am "TRETH".
* Ar ôl llong, byddwn yn anfon e-bost atoch a rhowch y rhif olrhain i chi.
|
|
|
Am Warant.
Cysylltwch â'r UD --- >> Dychwelwch yr eitem atom --- >> Derbyn ac anfon un arall yn ei lle.
Enw: Liu xiaoxia
Cyfeiriad: 305Fang HuiLanGe HuangPuDaDaoXi 273Hao TianHeQu Guangzhou Tsieina.
ZIP: 510620
Ffôn: + 8618078869184
Dychwelwch i'r cyfeiriad hwn ac ysgrifennu eich cyfeiriad paypal, enw, problem ar nodyn: |
|
