RADIOSITE.HU | Fórum

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.

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.

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.

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.

Féligazságot teljessé tenni, tényt közölni véleményem szerint soha sem értelmetlen.

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.

Adott buffer méretet viszont hamarabb megtölt a nagyobb bitsűrűség, így kisebb lesz a késés.

Gr3g0ry írta:

dkemeny77 írta:

Gr3g0ry írta:Időnként beberrrrrreg,fagyogat,akadozik vagy elnémul 1-2 mp-re.
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.

Gr3g0ry írta:

dkemeny77 írta:

Gr3g0ry írta:Időnként beberrrrrreg,fagyogat,akadozik vagy elnémul 1-2 mp-re.
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.

dkemeny77 írta:

Gr3g0ry írta:Időnként beberrrrrreg,fagyogat,akadozik vagy elnémul 1-2 mp-re.
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?