[Netia]

Zmniejszanie opóźnienia na siłę daje w wyniku  jeden lub więcej skutków poniżej:

- zmniejszenie GOP-a zwiększa bitrate  albo  pogarsza jakość kompresji mpeg

- zmniejszenie buforowania w STB zwiększa ryzyko przerw i zamrożeń w playoucie w wyniku zmiennej chwilowje jakości sieci 

- zmniejszenie segmentacji (jeśli w przyjętym rozwiązaniu nie jest ściśle związane z GOP-em) zwiększa liczbę requestów i plików na CDN

- zmniejszenie długości łańcucha proxy w CDN (liczby pośrednich serwerów w hierarchii) pogarsza efektywność cachowania i wymaga większych łącz w strukturze CDN-a (ergo kosztuje więcej a nic realnie nie daje)..

- optymalizacja pipeline headendu (gdzie transkoder zwykle zasila ingest serwer, a ten zapisuje na system dyskowy i z tego dane pobiera segmenter/szyfrator do origina CDNu) 

  polegająca na ominięciu zapisu na storage na ścieżce do odtwarzania live, po pierwsze kosztuje ekstra hardware, po drugie  psuje ciągłość miedzy live, pauzą i przewijanien w timeshifcie. 

 

I to w tym elemencie ( położenie strumienia na storage ) zwykle  pojawiają się te 30+ sekundowe opóźnienia - lepiej nie ryzykować wysypania się procesów przez czytanie zalockowanych/niedostępnych obiektów/plików.

 

Tym niemniej są akademickie eksperymenty (ale biznesowo jednak abstrakcyjne) zmniejszające opóźnienia live do nawet mniej niż określony czas GOP-a.

https://www.gpac-licensing.com/2014/07/09/lowering-dash-live-latency-240ms/

 

Poza tym to opóźnienie (30s+) tak naprawdę 99% większości nic a nic nie przeszkadza;   (poza fanami jak @Krzysiek_ co oglądają naraz mecz i metadane .

Negatywne hype o streamingu powtarza jak mantrę  multicastowa i satelitarna konkurencja....  ( a playerbox n-ki też ma 40s+)

 

Opóźnienie zawsze będzie delikatne, kwestią jest by je na maxa zmniejszyć.

 

 

 

 

... 

I z tego co pamiętam to chyba IPTV Netia nie działała na ADSL, chyba tylko ETTH i vdsl.

 

 

 

Działała i nadal resztkami działa - m.in. na DSLAM-ach pewniej izraelskiej firmy co nie odróżnia snoopingu od proxy...

 

Pierwszy multicast IPTV odpalony był na mini dslamach ADSL Ericssona ok. 2005 r, co wymagało

rekonfiguracji całej sieci dostępowej z Q-in-Q na bardziej płaską, bo igmp reporty nie były przetwarzane przez switche Cisco w podwójnie tagowanych ramkach.

To niestety zwiększyło skutki wpływu niestabilności topologii sieci dostępowej Ericssona na większe obszary MST (spanning-tree) z vlanem multicastowym.

Od koszmarów z działaniem multicastów w tamtym czasie nie posunięto się znacznie do przodu.

Dialog miał podobne obserwacje i problemy i dopuszczał nawet ręczne rekonfigurowanie kierunku uplinku vlanu multicastowego przy awarii ringu dostępowego.

 

Nowi producenci (chińscy i nie tylko) nie mając doświadczonych inżynierów popełniają nadal te same błędy. 

Przetwarzanie multicastów w sprzęcie sieciowym różni się drastycznie od unicastów, często to odrębne chipy

na kartach matryc przełączających w routerach, z ukrytymi limitami pasma, z trudnościami hash-owania na łączach zwielokrotnionych itp. itd. 

 

I jeszcze jedna dygresja:

Bazowo jakość obrazu w streamingu i multicaście jest taka sama.

Przeskoki jakości obrazu w streamingu są rezultatem takiej sytuacji w sieci, przy której multicast skutkowałby zakłóceniami i przerwami w obrazie i dźwięku w ogóle. 

 

Natomiast dostępność usług  YT, Netflix, róźne VODy wywołuje taką samą niepohamowaną konieczność rozbudowy pasma w sieci.

[Netia]

Dobre źródło to nie tylko Evio, to przede wszystkim kwestie umowne i negocjacyjne. 

Do serwerowni Netii od lat dochodzą wszystkie kanały z paczki C+ w jakości nieskompresowanej HD-SDI (2,7 Gbps każdy) na potrzeby NC+ GO.

Odbierane są jednak w oficjalnej jakości po kompresji takiej jak na sat i to wchodzi na transkodery do streamingu, gdzie liczba i bitrate profili adaptacyjnych

jest ustawiona jako _zaakceptowany_ po testach  kompromis miedzy rodzajem treści, obciążeniem transkoderów, wykorzystaniem storage w giganagrywarce, pojemnością CDN-a.

Tak jest dla większości kanałów włącznie z odbieranymi od evio.

 

Uwierz mi że multicast wcale nie jest dobrze znany i dopracowany.

Sprzęty sieciowe wcale nie zachowują się zawsze tak samo z multicastem pod obciążeniem i np. zmianą topologii przy awarii.

 

Na klienckich dostępach DSL są zakłócenia impulsowe i minimalne straty - w multicaście niezauważalny dla Internetu poziom BER-a 10e-6

jest grubo widoczny, przez to włączany jest na problematycznych liniach duży Interleaving w DSL i zwiększa się opóźnienie o 20ms. Gracze psioczą.

W multicaście czas przełączania to srednio 3s (jeśli np. w H.264 GOP jest 2 sekundy jest od 2 do 4 sekund).

Pomysły typu FastChannelChange i VQE z użyciem bufora kołowego do startu i uzupełniania strat unicastem

są drogie, trudne we wdrożeniu i fatalne w integracji z oprogramowaniem słabszych STB. 

Jako user streamingu pierwszy plułbyś sobie w brode że to tak fatalnie się przełącza.  (weź TV z niższej półki i poprzełączaj naziemną).

 

Multicast nie chodzi na mniejszych łączach niż najwyższy chwilowy bitrate (a surowe TS-y z satelity to zwykle VBR z multipleksera statystycznego).

Headend multicastowy Netii również przerabiał VBR-y do niższych przepływności i CBR-ów. Jak kiedyś w Polsat przez przypadek wypuścił do kablówek podwójny bitrate

z null ts-ami to był krzyk na całą polskę bo posypały się multipleksery na headendach, w Netii transkodery sobie poradziły.

 

Multicast nie będzie chodził na otwartym Internecie. Streaming nie ma z tym problemu.

Netiowy streaming potrafi działać bez stresu na 2 megowym Wimax-ie. 

 

Modernizacja streamingu to (poza nowinkami jak hevc) dostawianie serwerów edge bliżej tego edge-a.

Jest tańsze niż ciągłe walki z dziwnymi zmianami zachowań igmp proxy w kolejnych wersjach firmware na OLT, switchach ETTH, QoS-em na CPE itp.

 

Zapomnij o multicascie, po prostu go już nie będzie, jest w TCO droższy. Nawet zbieżny pomysł żeby w HFC Netii w planie kanałowym zostawić mały zakres dla multiplexu DVB-C/T albo dla mac domeny dla IP multicast-u został odłożony na półkę a potem do kosza.

 

Przede wszystkim:
O Evio to był skrót myślowy, może zbyt ogólnie to napisałem.
Chodziło mi o to by sygnał ten już nie rekompresowac i przetwarzać stratnie na Streaming.
To stwarza dosyć że opóźnienie sygnału to do tego jeszcze jakość jaką mamy.

Co do multicastu to ETTH jest modernizowane i będzie w pełni nowoczesne. Linie przejęte dziś są mocno przebudowywane, a PON powinien spokojnie dać radę.
Widzisz, Jambox dał unicast tylko w nPVR i VOD, o to właśnie chodzi by usługi unicastowe były sobie jako unicast (bo inaczej się przecież nie da, chyba że jak VOD w satelicie), a TV linearna której używa zdecydowanie więcej osób na multicast.

Wszystko tak naprawdę to kwestia konfiguracji. Da się spokojnie.
Unicast można dać jeszcze na innym vlan tak jak chociaż by robi Orange.
Oczywiście mogą iść tą drogą o której Ty mówisz tylko to będzie wymuszalo co chwilę modernizacje bo ruch będzie mocno się zwiększać.
I co najważniejsze:
Rozwiązanie multicast jest już znane i w pełni dopracowane.

[Netia]

Przestan już marudzić o tym multicascie i zapychać forum. Od streamingu nie ma odwrotu. 

 

Multicast w Netii był na samym początku,  wprowadzony na sieć ADSL only jeszcze, z różnymi ograniczeniami w zakresie QoS.

Plus kolejne akwizycje małych ISP rozszerzały sieć o totalnie różne technologie (DSLamy bez QoS  i niezarządzane switche Eth)

co powodowało niezdolność do spójnego dostarczania zawsze bezbłędnego strumienia.  Przejście na unicast wyleczyło wiele z tegoż.

 

W multicascie nie ma timeshifta, catchupu i vod-ów.

Jambox też dodał unicast dla timeshifta i vodów i wpędzał swoich partnerów w bezsenność, bo muszą swoje łącza dotąd w tych samych vlan-ach rozdzielać dla QoS-a do innych klas lub osobnych vlanów.

Multicast na WiFi praktycznie nie działa, za to w streamingu znaczący procent przyjemnie sobie tego używa.

 

W unicast wystarczy, że dołoży się więcej mocy enkoderów i storage i będzie można włączyć kolejne wyższe profile w adaptive streaming. ( Ale nie u wszystkich ) 

W unicast też przejście na wydajniejszy HEVC to ewolucja a nie bolesny switchover po wymianie bazy STB.

Plus 4k się pojawi jak przyjdzie pora. 

 

Poza tym piszesz jakieś fikcje o evio - gdzie wpuszczanie gołych strumieni bez DRMa?  Z CDNa evio ?  Mylisz pojęcia kolego, więcej pokory.

 

Widać że nadal automat kuleje u co niektórych

Jedyne wyjście to wysyłać im taki tekst:

Czas serio wprowadzić multicast i IPTV, i tak pobieracie już obraz multicast z CDN Evio więc można to zrobić tak:



Obraz od evio bezpośrednio wpuszczać jako strumień multicastowy (zaoszczędzicie bardzo dużo pasma i praktycznie obniżycie do zera opóżnienie, większość nowych central i tak już jest do multicastu dostosowana) do stb tych co mają ftth>= 100, etth>= 100 i hfc, w tym samym czasie niech juz wasze serwery sobie zapisują obraz pod nPVR, CatchUpTV itp, technicznie spokojnie da się to rozwiązać.

Zmiany muszą być jak najszybciej, im więcej klientów będzie na STV tym gorzej będzie o zmiany.

 

 Internet: AS8819 C897V+MA5671A, 250M↓↑, TV: Azart+IPTV+SAT (CP/Netia/Jambox/playerbox)