RADIOSITE Fórum

  • Amadeus Rádió - Szolnok - 102.4 MHz

 #159439  Szerző: Gr3g0ry
 
kukac írta: Egyébként pedig egy ip-alapú streamet nem tekintünk realtime-átvitelnek, valamennyi késés mindig lesz.
Ez benne is van a pakliban kell a konvertáláshoz is az idő.Ezt a bitrátázos dolgot pedig kisérletezéssel mondtam bár ez bufferméret is mond valamit:tegyük fel hogy vannak a lejátszók ott más a puffermérettel vannak megáldva,némelyiknek nagyobb a buffere ott igen később töltödik fel ha pl.:32 kbit-es streamt akarunk hallgatni.Ebből indultam ki.
 #159438  Szerző: Gr3g0ry
 
frekivadasz írta:Elbeszélünk egymás mellett.

Csupán arra az egy mondatodra reagáltam. Az előzmény, vagy bármiféle adat lényegtelen e tekintetben.

Helyesen tehát: A késés a tömörítés mértékétől is, és a beállított buffer méretétől is függ.
Ezzel egyet is tudok érteni. :yes:
 #159437  Szerző: frekivadasz
 
Elbeszélünk egymás mellett.

Csupán arra az egy mondatodra reagáltam. Az előzmény, vagy bármiféle adat lényegtelen e tekintetben.

Helyesen tehát: A késés a tömörítés mértékétől is, és a beállított buffer méretétől is függ.
 #159410  Szerző: kukac
 
frekivadasz írta:Féligazságot teljessé tenni, tényt közölni véleményem szerint soha sem értelmetlen.
bizonyára, de itt nem ez történt, vagy talán te tudod ezt a két adatot? A nagyobb bitráta nyilván hamarabb felzabálja a buffert, így az hamarabb is ürül (=kisebb késés). Ha a buffert növeled, ismét nő a késés, tehát az az állítás, hogy a nagyobb bitrate hamarabb tölti a buffert, önmagában csak féligazság, mindkét paraméter kihat a latencyre. Nem tudjuk pontosan mi okozza a késést, attól is lehet, hogy túl nagy a buffer (mondjuk stabilitás miatt, stb.) Egyébként pedig egy ip-alapú streamet nem tekintünk realtime-átvitelnek, valamennyi késés mindig lesz.
 #159370  Szerző: kukac
 
frekivadasz írta:Adott buffer méretet viszont hamarabb megtölt a nagyobb bitsűrűség, így kisebb lesz a késés.
nem tudjuk hogy mekkora a modulációs vonal streamjének bitsűrűsége és mekkora a beállított bufferméret, így ez a beszélgetés értelmetlen is.
 #159345  Szerző: kukac
 
Gr3g0ry írta:
dkemeny77 írta:
Gr3g0ry írta:Időnként beberrrrrreg,fagyogat,akadozik vagy elnémul 1-2 mp-re. :gülü2:
Szerintem a CPU felugrik 100%-ra.

Egy darabig a Civilnél volt hasonló problémánk, valószínűleg interneten küldik az adóhoz a jelet, és az adatfolyamból pár csomag elveszik. Valami ilyen volt nálunk...
Hogy is van ez a internetes továbbítás?
Van egy stream az adónak,és van egy stream a hallgatóknak,de a hallgatóé késik néhány mp-et.Vagy talán 512-es rátával tolják hogy ne legyen akkora késés?
A késés nem a tömörítés mértékétől, hanem a beállított buffer mérettől függ.
 #159332  Szerző: dkemeny77
 
Gr3g0ry írta:
dkemeny77 írta:
Gr3g0ry írta:Időnként beberrrrrreg,fagyogat,akadozik vagy elnémul 1-2 mp-re. :gülü2:
Szerintem a CPU felugrik 100%-ra.

Egy darabig a Civilnél volt hasonló problémánk, valószínűleg interneten küldik az adóhoz a jelet, és az adatfolyamból pár csomag elveszik. Valami ilyen volt nálunk...
Hogy is van ez a internetes továbbítás?
Van egy stream az adónak,és van egy stream a hallgatóknak,de a hallgatóé késik néhány mp-et.Vagy talán 512-es rátával tolják hogy ne legyen akkora késés?

Nem tudom ott hogy működik, mi két streamen toljuk, ahogy fentebb írtad.
 #159287  Szerző: Gr3g0ry
 
dkemeny77 írta:
Gr3g0ry írta:Időnként beberrrrrreg,fagyogat,akadozik vagy elnémul 1-2 mp-re. :gülü2:
Szerintem a CPU felugrik 100%-ra.

Egy darabig a Civilnél volt hasonló problémánk, valószínűleg interneten küldik az adóhoz a jelet, és az adatfolyamból pár csomag elveszik. Valami ilyen volt nálunk...
Hogy is van ez a internetes továbbítás?
Van egy stream az adónak,és van egy stream a hallgatóknak,de a hallgatóé késik néhány mp-et.Vagy talán 512-es rátával tolják hogy ne legyen akkora késés?
  • 1
  • 2
  • 3
  • 4
  • 5
  • 14