Hoe 'live' is live-TV eigenlijk nog?

[WalterB1]

Hallo,

Geen vraag echt, meer een observatie die mij interessant lijkt om wat over te keuvelen.

Ik ben DVB-T kijker, heb sinds kort AntenneTV van TVV. En momenteel zijn de zenders van de nog VRT beschikbaar via DVB-T free-to-air en zijn ze ook opgenomen in de bundel van TVV.

Daardoor kon ik eenvoudig een TV op Een via DVB-T zetten en een andere op Een via AntenneTV. Het signaal via AntenneTV loopt achter. Serieus. Heb het getimed en het is 17 seconden dat de live-tv achterloopt tegenover DVB-T. En er zal al vertraging zitten op het signaal via DVB-T zelf.

Dat doet mij afvragen; hoe 'live' is live-tv eigenlijk nog tegenwoordig?

[Tomby]

Live zal nooit echt live geweest zijn IMHO. Ook vroeger had je al dat je bvb kon hebben dat het geluid op radio van live uitzendingen voorliep op wat op TV te zien was. Was vervelend als je bvb bij een voetbalmatch liever naar Jan Wauters luisterde.
Een vertraging van 17 seconden lijkt me nog altijd 'live' genoeg, eerlijk gezegd.

Je kan je al meer vragen stellen bij bvb US praktijken waarbij ze live uitzendingen doelbewust vertragen zodat ze kunnen previewen wat er op antenne gaat en direct ingrijpen als er iets komt dat hun niet aanstaat (blote tepel, streaker, anti-Trump toeschouwer, ...).

[mailracer]

Er komen zoveel technische zaken bij kijken dat het logisch is dat er vertraging aanwezig is.
- Hoeveel switchen en nodes passeert het beeld niet op het netwerk van een provider alleen ?
- Wat gebeurd er met het signaal van een zender voor het klaar is om naar de tv-providers te sturen, vertraging door - en bufferen voor - coderen ?

Het enige probleem dat ik hieruit kan afleiden is het stemmen in live-shows waarbij de laatste stemmen verloren kunnen gaan omdat de kijker seconden te laat geïnformeerd word.

[Thomaz]

Het gros is herhaling van een herhaling, dat er op een rechtstreekse uitzending dan een 20 tal secondes vertraging zit door het gebruikte protocol lijkt me weinig schokkend

[boulder]

Het zou mij waarschijnlijk alleen storen bij sportwedstrijden.
Stel dat jij een voetbalmatch aan het bekijken bent, en je buurman is diezelfde match aan het volgen.
Je hoort hem juichen, en 17 seconden later zie je dan bij jou dat er een doelpunt is geweest.
Dat zou niet zo leuk zijn.

[phil48]

Het zou mij waarschijnlijk alleen storen bij sportwedstrijden.
Stel dat jij een voetbalmatch aan het bekijken bent...

Had ik tijdens het jongste WK. Er stonden twee matchen op, naast elkaar op twee tv's. Eentje met digicorder Telenet, andere met satelliet. Toen ik even beeldkwaliteit wou vergelijken (superieur op BBC satelliet) zag ik dat de satelliet wel seconde of twee trager was.

Niet erg - want tenslotte staat die tv toch niet zo stil dat je de buurman over jouw geluid heen kan horen juichen, toch?

Anderzijds, zeventien seconden is wel héél lang.

[ubremoved_539]

Het gros is herhaling van een herhaling, dat er op een rechtstreekse uitzending dan een 20 tal secondes vertraging zit door het gebruikte protocol lijkt me weinig schokkend

Het lijkt me nochtans absoluut niet normaal... tenzij de bron via sat tot in de regie komt en ook nog eens terug via sat naar de klant moet maar zelfs dan is meer dan 5 seconden toch echt wel abnormaal.

[raf1]

Eigenlijk zijn secondelange vertragingen schandalig. In het analoge tijdperk was alle tv en radio quasi perfect live. Analoge kabel-tv, analoge antenne-tv en FM-radio. Tussen tv-studio en tv-toestel bij de kijker thuis was er zeker geen seconde vertraging. Hoogstens enkele tientallen milliseconden.
Ik herinner me nog dat het geluid een beetje galmde als je in de living naar een voetbalwedstrijd keek via analoge kabel-tv en in de keuken de FM-radio opzette. Galm heb je bij vertragingen tot 50 milliseconden, daarna wordt het echo. Tv was dus écht live.

17 seconden vertraging is wél echt te gortig. Dan is de live-ervaring toch om zeep. Zeker nu tv-omroepen bij live-programma's de kijker aansporen om via sociale media te reageren op het live-gebeuren.

[blaatpraat]

Hou rekening met de snelheid van het licht (niet in vacuüm): 200000km/s.
Dit lijkt snel, en een verwaarloosbare factor, maar is het niet.
Dit is de eerste plaats van vertraging tijdens het transport, als je gebruikt maakt van het snelste dat er is (bijvoorbeeld met glasvezel).

Als je digitaal werkt, moet je rekening houden met encoderingen en transcoderingen.
Hoe meer compressie je toepast op je signaal, hoe langer dit duurt.
Als je rekent dat een 1080i signaal (standaard in de broadcast) zo'n 1.5Gb/s groot is, en uiteindelijk schiet er hier zo'n 10Mbps nog van over als je dit op je TV krijgt...

Bij satelliet mag je rekenen op 250ms vertraging tussen grondstation en zwevend station.
Als je een rechtstreekse link hebt, is dit al 500ms.
Wordt er satelliet gebruikt voor uitzendingen tussen remote site en regie-site, is er dus 500ms vertraging, en dus 1s tot bij de volgende node (distributeur wellicht).

Als je via IP werkt (nog niet ingeburgerd in de broadcast, maar men is bezig met de transitie), moet je rekening houden dat iedere node voor een vertraging zorgt (iedere keer de mac table uitlezen op een L2 switch bijvoorbeeld).
Ook hier spreken we over milliseconden, maar iedere gecumuleerd kan dit tellen.

Nu, in dit geval:
Het signaal van AntenneTV komt van M7.
Dit wilt zeggen dat het vanuit Brussel naar een distributeurspunt in Vlaanderen gaat, vanwaar het naar Luxemburg (zetel M7) gaat, vanwaar het naar Sint-Pieters-Leeuw gaat (zetel Norkring), vanwaar het verspreid wordt over een IP-netwerk naar alle DVB-t punten om dan gemoduleerd te worden als DVB-T signaal in de ether.
Het signaal van VRT gaat rechtstreeks naar alle DVB-t punten, dus het beginpunt en de laatste stappen zijn gelijk, de andere zorgen allemaal voor vertraging. Bij het transport hiervan wordt er enkel gebruik gemaakt van glasvezel zonder encodering, dus dit gaat met de snelheid van het licht.

17s is veel, maar verbaast me niets.

[WalterB1]

17 seconden vertraging is wél echt te gortig. Dan is de live-ervaring toch om zeep. Zeker nu tv-omroepen bij live-programma's de kijker aansporen om via sociale media te reageren op het live-gebeuren.

Het is TV Vlaanderen. Zou het niet kunnen dat het signaal dat Norkring krijgt binnenkomt via sateliet?

Als dat zo zou zijn dan moet de keten ongeveer zijn;
Het uplink-station dat TV VLaanderen gebruikt krijgt van ergens het signaal binnen. - Het moet door de computers van het uplinkstation en hop, naar boven. Het moet door de computers van de sateliet heen en dan terug naar beneden. Daar is ook hardware om dat signaal om te zetten naar een output, dat zal ook weer enige tijd vergen. Dan heeft Norking het signaal. Die zullen er ook nog wel iets mee uitvoeren en die moeten het dan verdelen naar al hun diverse zendmasten in Vlaanderen. Nog eens zenden en ontvangen. Zendmasten gaan het dan uitzenden via de ether. Mijn kleine antenne vangt dat signaal op en dan moet het door mijn DVB-T2 ontvanger in samenwerking met de CI+ module omgezet worden naar beeld en geluid.

Misschien is 17 seconden nog zo gek niet.

[Joe de Mannen]

Zelfs tussen telenet analoog en telenet digitaal zitten seconden verschil.
Radio over internet is ook trager dan fm radio. Nooit aan spelletjes 'de snelste beller wint' meedoen

J.

[ubremoved_539]

17s is veel, maar verbaast me niets.

Als je alles optelt wat je hebt geschreven kom je worst case aan een goeie seconde... 17 seconden verbazen me dan ENORM !

Ik wil dus wel eens weten bij welke provider dit is en wat de referentie is ? Volgens mij wordt hier sterk overdreven.

[blaatpraat]

17s is veel, maar verbaast me niets.

Als je alles optelt wat je hebt geschreven kom je worst case aan een goeie seconde... 17 seconden verbazen me dan ENORM !

Ik wil dus wel eens weten bij welke provider dit is en wat de referentie is ? Volgens mij wordt hier sterk overdreven.

VRT -> M7 (vlaanderen): glasvezel, paar milliseconden
M7 (vlaanderen) -> M7 (luxemburg): encoderen naar IP (paar seconden) + transport (milliseconden) + decoderen (seconden)
Uplink naar satelliet, downlink in Sint-Pieters-Leeuw: ongeveer 500ms (transport) + encoderen en decoderen (paar seconden)
Encoderen op IP-netwerk Norkring (seconden), transport over IP netwerk (milliseconden), decoderen in zendstation (seconden)

Versus
VRT -> zendstations (glasvezel, milliseconden)

Hierna wordt het signaal gemoduleerd op antenne, en is de vertraging gelijk tussen beide situaties.
Een goede vergelijking zou het Antenne-TV signaal samen met het Satelliet signaal zijn, daar is het transport (en coderingen en dergelijke) naar Luxemburg al gelijk in vertraging.

[apestaart]

Zelfs tussen telenet analoog en telenet digitaal zitten seconden verschil.
Radio over internet is ook trager dan fm radio. Nooit aan spelletjes 'de snelste beller wint' meedoen

J.

Er is een verschil tussen Telenet digitaal via CI+ module en Telenet digitaal via digibox/digicorder, dat laatste loopt iets achter tegenover de DVB-C tuner.
Het signaal via Proximus TV loopt het verst achter tegenover Telenet.

[ubremoved_539]

encoderen naar IP (paar seconden)

Ik weet niet over welke middeleeuwse encoders/decoders jij nog spreekt maar die dingen gebeuren quasi real-time tegenwoorig.

Dit is bijvoorbeeld uit een document van Intel;

End-to-end (inclusief netwerk) zit men dus aan ongeveer 21ms !

[satellitetv]

Ik kijk TV via satelliet en heb wel gemerkt dat de uitzendingen (via tv vlaanderen) zo'n 10 tot zelfs 30 seconden achterlopen op het kabel tv signaal van dezelfde zender. Komt waarschijnlijk omdat tv vlaanderen eerst het signaal naar de satelliet moet sturen en daarna ontvangst met de schotelantenne. Je ziet dit verschijnsel ook vaak bij rechtstreekse verbindingen naar een verslaggever. Heeft ook vertraging.

[ubremoved_539]

Radiosignalen gaan tegen 300.000 km/s, de latency veroorzaakt door een sat up/downlink (2 x 36.000 km)... bedragen dus maar iets van een 250 ms. Ik wil dus wel eens weten waar die andere 9.750 tot 29.750 seconden dan aan verprutst worden want aan encoding/decoding kan het ook al niet zoals hierboven vermeld.

[laroyj]

als wij met de radio een live uitzending maken hebben wij via het RTP(real time protocol) protocol voor audio 100-600 msec, afhankelijk van de gebruikte codec,( PCM=wav = 100msec, maar mp3, omwille van de compressie is al 600 msec, en dan spreken we nog maar alleen van audio), gebruiken we icecast, is het een paar sec, gebruiken we een shoutcaststream is het al 10-15sec, vanwege de buffering.
Wanneer we een sateliet uplink gebruiken via de tooway KA-SAT zitten we aan 500msec extra voor de uplink e nog eens 500msec voor de downlink, bij te tellen, bij de andere latency.. als we dan nog eens gebruik maken van softwarematige processing kan daar gerust nog 2 sec , alleen daarvoor bijkomen...

Dit alles vind ik heel hinderlijk en zorgt ervoor dat we altijd moeten luisteren naar de PA ipv naar de radio op een event, en zrgt er ook voor dat er bijna altijd gebruik wordt gemaakt van een retourkanaal naar de studio (het oortje van de reporter) , om elkaar syncroon te horen, gebruik van voip via sateliet internet is daarom ook niet echt bruikbaar, omwille van die latency...

[fredo66]

Ook bij de radiouitzendingen is er enkele seconden verschil tussen de verschillende platforms: ik luister fm radio, dab(+) en dvb-t radio.
FM is snelst, dab het traagst.

Voor TV : wat is daar nog echt live hé, haast geen enkele uitzending gaat helemaal live (behalve journaal dan). Zelfs politieke verkiezingsdebatten op
locatie worden steeds uitgezonden met een vertraging van zo'n 7 tal minuten. Geen montage dus maar wel de mogelijkheid om het niet uit te zenden indien iemand uit het publiek iets ongewenst zou doen

[laroyj]

allemaal te zien hoe het signaal technisch aangeleverd wordt en of het idd nog via een extra eindregie moet passeren..
bij analoge zicht straalverbindingen is er bijna geen latency bij AOIP/VOIP/IPTV is de latency afhankelijk van de codec en aantal hops en compressie

[ubremoved_539]

gebruiken we icecast, is het een paar sec, gebruiken we een shoutcaststream is het al 10-15sec, vanwege de buffering.

Op zich lijkt me dat een slechte instelling op de server... normaal komt een jitterbuffer overeen met je maximale latency.

Trouwens ik zie niet in waarom je icecast/shoutcast zou moeten gebruiken voor punt-tot-punt verbinding... kijk eens naar het AES67 protocol, bestaan low cost toestelletjes voor zoals deze die de klus doen in enkele milliseconden !

als we dan nog eens gebruik maken van softwarematige processing kan daar gerust nog 2 sec , alleen daarvoor bijkomen...

Dan spreek je ook niet over professionele apparatuur.

[laroyj]

het gaat allemaal over professionele apparatuur, kunnen we ons als radiostation niet veroorloven, van ons met speelgoed bezig te houden of systemen die niet bedrijfszeker zijn... het shoutcastprotocol heeft nu eenmaal een gemiddelde latency van 10-15sec, dat heeft niks met jitter te maken of de audiocodec, enkel RTP is bijna real time....

software processing betekent coderen/decoderen/compressie etc, in ons geval doet dezelfde software, naast de processing ook nog de stereo encoding en rds encoding, en deze software zit ook in de orban en omnia procesoren die tot 15.000 euro kunnen kosten..

het goedkope toestelletje doet het in theorie idd in 20msec, moet je het dan in de praktijk eens uittesten, zefs met een ubiquiti zichtverbinding krijg je nog last door jitter waar door je het best niet minder zet dan 200msec, en als je het dan nog eens via het vaste internet moet doorsturen kan het zijn dat je het nog langer moet zetten...

Vorige week nog aan het discuteren geweest met de maker van stereotool, de softwarematige processor die het in theorie via asio op 50 msec doet, maar gebruik je een usb geluidskaart, heb je ook alweer extra latency, en hoe meer opties je gebruikt, komt er telkens wel weer wat bij, in ons geval komt dat met low latency op minstens 200-300msec maar met stereo/rds erbij ga je volgens de theorie naar 500-600msec, in de praktijk is het bijna 2sec... vandaar dat we terug gaan overschakelen naar enkel hardware om binnen de 200 msec zouden blijven...

[bitbite]

encoderen naar IP (paar seconden)

Ik weet niet over welke middeleeuwse encoders/decoders jij nog spreekt maar die dingen gebeuren quasi real-time tegenwoorig.

En dan heb je een codec met een lange group of pictures en zit je meteen inherent aan seconden vertraging, los van de processorkracht.

Maar 17 seconden -> dat is echt zeker een transport buffer ergens, ik kan me geen enkel ander mentaal gezond scenario voorstellen. Ik kan uit de eerste hand getuigen dat in die wereld wel echt amateuristische setups voorkomen, dus het zou me nog echt niet verbazen mochten ze een internet stream opnieuw broadcasten ofzo.

[johan.devos]

Naar aanleiding van het wereldkampioenschap voetbal heeft men dit eens deftig nagemeten in Duitsland in de c’t 2018-11:

[ubremoved_539]

het gaat allemaal over professionele apparatuur, kunnen we ons als radiostation niet veroorloven

Inderdaad... ik denk dat een VTM (content provider) of een TN (content distributor) niet met "speelgoed" werken.

En dan heb je een codec met een lange group of pictures en zit je meteen inherent aan seconden vertraging, los van de processorkracht.

Je hebt het over de diverse keyframes dan ? Nee, ook dat is geen probleem.

Maar 17 seconden -> dat is echt zeker een transport buffer ergens, ik kan me geen enkel ander mentaal gezond scenario voorstellen.

Maar wat is de zin van een buffer als je geen retransmission kan vragen (zoals bij broadcast). Enkel bij individuele streams zoals bijvoorbeeld Netflix, Spotify, ... zou dit zinvol zijn.

Naar aanleiding van het wereldkampioenschap voetbal heeft men dit eens deftig nagemeten in Duitsland in de c’t 2018-11:

Hier zie je het duidelijke bewijs dat het wel kan... sat HD heeft maar 1 a 2 seconden (moeilijk te zien op de schaal) latency en moet ook encoding en decoding doen, en tevens nog transport dat minder snel is dan internet.