Casema knijpt de bitrate van veel digitale TV kanalen

Sinds het digitale TV signaal van Multikabel bij Casema vandaan komt hebben de Multikabel klanten te maken met een nieuw fenomeen, namelijk het knijpen van de bitrate van digitale kanalen door de provider, in dit geval Casema. Het andere Zesko/Ziggo kabelbedrijf @Home past in principe geen bitrate beperkingen toe op digitale kanalen, dus alleen de Ziggo klanten in het Casema/Multikabel gebied krijgen door het beperken van de bitrate een lagere kwaliteit geleverd dan technisch mogelijk is aangezien Casema zelf wel de volledige kwaliteit krijgt aangeleverd.

Begin maart heb ik op het TV Home forum de volgende overzicht gemaakt van de bitrate van de digitale TV kanalen met een constante bitrate zoals die destijds door Multikabel werden doorgegven in vergelijking met de huidige bitrate van die kanalen bij Casema. Achter de naam het TV kanaal is procentueel aangegeven hoeveel de gemiddelde bitrate lager of hoger is geworden nu het signaal bij Casema vandaan komt.



In dit overzicht heb ik de commerciele Nederlandse kanalen toegevoegd waarbij de aanname is gemaakt dat Multikabel die kanalen net als @Home met de volledige kwaliteit van het bron signaal zou hebben doorgegeven, dus afgerond zo'n 8,2 Mbps. De kanalen waarop die aanname van toepassing is hebben een sterretje achter de naam gekregen.

Eind november 2007 had ik ook al een dergelijk overzicht gemaakt. Voor degenen die willen vergelijken is hier de link naar het voorgaande plaatje. Sinds november vorig jaar zijn er uiteraard wel een aantal TV kanalen met een constante bitrate verdwenen die dus niet meer terugkomen in het nieuwe overzicht.

Het beperken van de bitrate van kanalen is volgens mij niet nodig gezien de hoeveelheid vrije ruimte die er nog in de Transport Streams aanwezig is of zou in ieder geval voor een groot aantal kanalen afgeschaft kunnen worden. Daarvoor moet dan wel de verdeling van de kanalen over de beschikbare Transport Streams aangepast worden, maar in principe is dat niet moeilijk aangezien Casema gewoon de indeling van @Home zou kunnen overnemen.

Overigens is het opmerkelijk dat Casema er uberhaupt voor kiest om TV kanalen met een constante bitrate te beperken aangezien in de handleidingen van Cisco, de leverancier van de apparatuur, het volgende is terug te vinden over het beperken van bitrates dat de Quality of Service (QoS) instellingen per digitaal kanaal wordt genoemd:

Modifying QoS

The choices are:

• VeryLow—Most rate reduction
• Low—Below average rate reduction
• Medium—Average rate reduction
• High—Minimum rate reduction
• VeryHigh—Least amount of rate reduction
• NoRateRed—Recommended for HDTV programs and other programs for which the full input quality must be preserved. This selection uses statistical multiplexing and takes up a DSP resource.
• PassThru—Recommended for low rate and constant bit rate applications, this selection does not use any DSP resources. The stream uses the predefined pass-through bandwidth.

Klik om te vergroten...

Cisco adviseert dus om PassThru te kiezen voor kanalen met een constante bitrate en geen bitrate beperking toe te passen.

Dit is zeker een slechte zaak! Net als toen ze probeerden meer in een transport stream te proppen dan mogelijk was, met haperingen en meer ongein tot gevolg.

Mooi overzicht Archie! Dit lijkt me ook een puntje voor de MGV, met mooie harde bewijzen van Archie.

@Archie: in die vet gedrukte opmerking van Cisco kan je natuurlijk ook gewoon lezen dat ze hiermee bedoelen dat als je geen behoefte hebt aan transraten , je de betreffende service op passthrough zet (applications != services).
Dit is wat anders dan erin lezen dat passthrough de aangeraden instelling is voor CBR services (in mijn optiek dan, jij mag dit best anders zien).
Je kan transraten ook zien als een verzekeringspolis, waarmee voorkomen wordt dat een service die in bitrate ineens onaangekondigd omhoog gaat de volledige TS om zeep helpt.
Iets wat vandaag 4 meg is, hoeft dat morgen niet meer te zijn...
Nog afgezien van TS'en waar de meeste services VBR zijn.

Ik zou overigens graag willen weten uit welke handleidingen dit citaat afkomstig is, even puur ter interesse overigens.

@Vincent: als er te weinig in een TS staat is het niet goed, als er teveel instaat is het ook niet goed. Make up your mind.

Verder vind ik deze soort grafieken (en dan zeker met bijbehorende opmerkingen) altijd redelijk komisch. Net of een verschil van 0,8 meg op een service van 8,2 meg zichtbaar is zonder analyser. Misschien wordt het tijd om gewoon tv te gaan kijken, ipv de hele dag naar de grafieken.
Ik zou je aanraden om eens te vergelijken met satelliet, daar komt de 8,2 in de verste verte niet bij in de buurt.

Just my 2c

Outsider zei:

@Archie: in die vet gedrukte opmerking van Cisco kan je natuurlijk ook gewoon lezen dat ze hiermee bedoelen dat als je geen behoefte hebt aan transraten , je de betreffende service op passthrough zet (applications != services).
Dit is wat anders dan erin lezen dat passthrough de aangeraden instelling is voor CBR services (in mijn optiek dan, jij mag dit best anders zien).

Klik om te vergroten...

Dan lezen jij en ik dat verschillend. Een "recommendation" is een aanbeveling en een "application" is een toepassing.

Je kan transraten ook zien als een verzekeringspolis, waarmee voorkomen wordt dat een service die in bitrate ineens onaangekondigd omhoog gaat de volledige TS om zeep helpt.

Klik om te vergroten...

Daarom stellen ze volgens mij ook dat de stream een voorgedefinieerde pass-through bandbreedte krijgt. Voor constante bitrate kanalen is die bekend.

Iets wat vandaag 4 meg is, hoeft dat morgen niet meer te zijn...

Klik om te vergroten...

Ik neem aan dat de kabelbedrijven op de hoogte worden gehouden door de signaal leveranciers van wijzigingen.

Nog afgezien van TS'en waar de meeste services VBR zijn.

Klik om te vergroten...

Veel wel, maar niet alles. Het gaat hier in dit topic in principe over de constate bitrate kanalen voor zover ik dat goed heb kunnen inschatten met de hobby tools die ik ter beschikking heb. Voor kanalen met een variabele bit rate zou het transraten eventueel gebruikt kunnen worden als "verzekeringspolis" mits de instelling op "VeryHigh" gezet wordt. Uit bovenstaande overzichtje blijkt wel dat het transraten bij Casema voornamelijk als middel wordt gebruikt om zoveel mogelijk kanalen in een Transport Stream te kunnen proppen omdat er hogere instellingen worden gebruikt dan een "verzekeringspolis" instelling zoals "VeryHigh". Dat zie je ook terug als er problemen optreden na kanalen wijzigingen waarbij een Transport Stream eigenlijk te vol komt te zitten. In plaats van ruimte te creëeren door de kanalen verdeling over de Transport Streams aan te passen kiest Casema er dan voor om een hogere bitrate beperkingsinstelling te kiezen in de hoop dat het probleem dan is opgelost.

ArChie zei:

Dan lezen jij en ik dat verschillend. Een "recommendation" is een aanbeveling en een "application" is een toepassing.

Klik om te vergroten...

Daar zullen we het dan denk ik over oneens blijven.
Als je een nadere verwijzing naar het document kan geven, dan wil ik mij daar echter best wel in verdiepen voor deze discussie.

Daarom stellen ze volgens mij ook dat de stream een voorgedefinieerde pass-through bandbreedte krijgt. Voor constante bitrate kanalen is die bekend.

Klik om te vergroten...

Als ik je goed begrijp dan ga je ervanuit dat je alle CBR bitrates optelt, en deze minimaal reserveerd als passthrough bandbreedte?
Ik vraag me af of je dit wel zou zou kunnen instellen.
Als je dan een bijvoorbeeld slechts 1 VBR service hebt, dan zet je deze alleen op rate limited?
Dan zou ik toch eerder alle services statmuxen, waardoor je klappen met de hele TS opvangt, in plaats van dat je de VBR doodknijpt.
Dat gedurende dit proces de mux dan meteen de overbodige data eruit perst met als gevolg dat alle services iets in bitrate naar beneden gaan is dan misschien meer een 'unfortunate side-effect'.

Ik neem aan dat de kabelbedrijven op de hoogte worden gehouden door de signaal leveranciers van wijzigingen.

Klik om te vergroten...

Ik help het je hopen. Hoeveel invloed zou Zesko hebben op bijvoorbeeld de diverse turkse zenders? Ik vraag het mij af. Bovendien is voorkomen beter dan genezen vind ik.
Mijn ervaring bij een non-Zesko kabelboer (niet Canal Digitaal overigens) is toch weleens anders.

Dat zie je ook terug als er problemen optreden na kanalen wijzigingen waarbij een Transport Stream eigenlijk te vol komt te zitten. In plaats van ruimte te creëeren door de kanalen verdeling over de Transport Streams aan te passen kiest Casema er dan voor om een hogere bitrate beperkingsinstelling te kiezen in de hoop dat het probleem dan is opgelost.

Klik om te vergroten...

Een service verplaatsen naar een andere TS heeft wel als gevolg dat het risisco aanwezig is dat deze uit de favorietenlijst valt. Het zou ook nog zo kunnen zijn dat er dan weer te weinig ruimte is voor toekomstige uitbreidingen. Een netwerk waar om de haverklap zenders van hot naar her springen is ook vervelend, dat zie ik wel op de satelliet).
Een transrate-rate (...) aanpassen lijkt mij minder ingrijpend dan een kanaal verplaatsen met alle PSI/SI wijzigingen vandien (zeker als ik jouw diverse posts zie met restpunten die soms in een TS achterblijven), maar dat zal wel per mux verschillen denk ik.

Outsider zei:

@Vincent: als er te weinig in een TS staat is het niet goed, als er teveel instaat is het ook niet goed. Make up your mind.

Klik om te vergroten...

Ik weet niet wat je hier mee wilt zeggen, maar deze opmerking bevalt me eigenlijk niet. We hebben het hier over twee verschillende dingen:

1. Casema beperkt de bandbreedte van de verschillende kanalen.
2. Ze stopten vroeger teveel in een TS.

Dat casema de bandbreedte beperkt voor verschillende kanalen wil niet automatisch zeggen dat hiermee sommige transportstromen niet vol zijn. Beide punten zijn losse 'problemen' met allebei een eigen uitwerking. Bij punt 1 zal bij de betreffende kanalen de kwaliteit afnemen en zie je allerlei vlekken etc in beeld. Bij punt 2 haperen kanalen af en toe of valt het beeld weg etc.

Er is ook nog zoiets als een gulden middenweg, je zegt het zelf al in je opmerking TE weinig en TE veel. Met een beetje beter indelen zou je wellicht tot betere kwaliteit van de kanalen kunnen komen zonder dat dit sommige transportstromen 'verstopt'

Om maar even een aloude helpdesk vergelijking uit de kast te halen. Als je met je auto op de snelweg rijdt kun je je gewoon aan de juiste snelheid houden. Maar je kunt ook te snel of te langzaam rijden, beide is vervelend voor overige weggebruikers en beide heeft zijn eigen nadelige gevolgen.

Misschien wordt het tijd om gewoon tv te gaan kijken, ipv de hele dag naar de grafieken.

Klik om te vergroten...

Dit ben ik met je eens.

Een netwerk waar om de haverklap zenders van hot naar her springen is ook vervelend, dat zie ik wel op de satelliet).

Klik om te vergroten...

Je moest eens weten wat wij allemaal al meegemaakt hebben bij Multikabel.

Verder vind ik deze soort grafieken (en dan zeker met bijbehorende opmerkingen) altijd redelijk komisch. Net of een verschil van 0,8 meg op een service van 8,2 meg zichtbaar is zonder analyser

Klik om te vergroten...

Is ook wel waar, maar je moest eens weten hoe hard er altijd geschreeuw is 'wij doen niets aan de bandbreedte van de kanalen' etc.
Ik zit er verder ook niet mee dat de bandbreedte beperkt wordt, maar ik durf te wedden dat ze nu op de helpdesk nogsteeds roepen dat de kanalen direct zonder enige bewerking doorgestuurd worden.

Dit was je wisselgeld

Outsider zei:

Een service verplaatsen naar een andere TS heeft wel als gevolg dat het risisco aanwezig is dat deze uit de favorietenlijst valt.

Klik om te vergroten...

Als de Service ID gelijk blijft is er volgens mij geen gevaar voor de favorietenlijst. Dat veel kabelbedrijven die ID's nummeren op basis van de Transport Stream waarin ze zijn opgenomen kan ik niets aan doen. Gelukkig zien we nu bij Zesko/Ziggo dat ze dat verband aan het loslaten zijn al hangen ze nog steeds een bepaalde betekenis aan die Service ID's.

Het zou ook nog zo kunnen zijn dat er dan weer te weinig ruimte is voor toekomstige uitbreidingen. Een netwerk waar om de haverklap zenders van hot naar her springen is ook vervelend, dat zie ik wel op de satelliet).

Klik om te vergroten...

Een probleem dat je eeuwig zal blijven houden. Van tijd tot tijd zal er weer een Transport Stream bij moeten of ze moeten kanalen schrappen. Het is nu eenmaal een dynamische wereld.

Een transrate-rate (...) aanpassen lijkt mij minder ingrijpend dan een kanaal verplaatsen met alle PSI/SI wijzigingen vandien (zeker als ik jouw diverse posts zie met restpunten die soms in een TS achterblijven), maar dat zal wel per mux verschillen denk ik.

Klik om te vergroten...

Dus om het voor het bedienend personeel zo eenvoudig mogelijk te maken moet er maar voor het beperken van bitrates gekozen worden want dan is de kans op menselijke fouten kleiner. Dit is hun vakgebied en ik ga er vanuit dat ze over betere tools beschikken dan ik. Ook weten ze hopelijk wat ze aan het doen zijn, dus is het voor hen eenvoudig om te controleren of alles goed verlopen is na wijzigingen. Bij goede nacontrole van hun eigen werkzaamheden zou ik dergelijke fouten niet eens mogen constateren.

Over het algemeen wordt er eerst getest met een nieuw kanaal voordat deze beschikbaar gemaakt wordt aan klanten. Er is dan toch wel redelijk in te schatten welke bitrate het kanaal gebruikt en of een nieuw kanaal gaat passen binnen een Transport Stream. Een voorbeeld hiervan is FanTV. In januari is hiermee uitgebreid getest en toen was al duidelijk dat FanTV te veel is voor deze Transport Stream. Gevolg: Destijds veel pogingen om de boel stabiel te krijgen met het beperken van bitrates. Gisterenavond is FanTV daadwerkelijk live gegaan en uiteraard neemt FanTV nog steeds te veel ruimte in beslag waardoor de vrije ruimte voor het opvangen van bitrate pieken weer gevaarlijk klein is geworden. Alle bitrate beperkingsinstellingen van de testen in januari zijn niet overgenomen, dus kunnen we er op wachten dat we nog een keer deze procedure kunnen doorlopen. Als resultaat van die testen in januari had Casema echter ook kunnen besluiten om FanTV bij voorbaat al te verhuizen naar een andere Transport Stream waar wat meer ruimte was voor dit kanaal. Klanten zouden dan geen last hebben gehad van eventuele favorietenlijst problemen.

Wat mij als sportliefhebber uitermate stoort is dat de beeldkwaliteit van sportwedstrijden op zenders als Sport1 en Eurosport (1 en 2) erg slecht is op een grotere LCD TV. Op mijn 46" LCD TV (aangesloten op SD-decoder) zijn de gevolgen van m.i verkeerde zuinigheid zo duidelijk en irritant aanwezig dat het kijkplezier vernaggelt wordt. En of dit nou door verkeerde/te hoge compressie en/of een te lage bitrate veroorzaakt wordt interesseert mij eigenlijk niet (black box). Ik constateer wel dat de kwaliteit van sportwedstrijden op NED, RTL en SBS vaak stukken beter is, hoewel dit ook zeker nog niet optimaal genoemd kan worden.
Feit is dat er voor een aanvaardbare beeldkwaliteit bij sportwedstrijden meer nodig is (minder compressie c.q. hogere bitrate ??) dan voor het uitzenden van een studiogesprek met weinig actie.
Zeker van de Sport1-kanalen, waar je aparte abonnementskosten voor moet betalen, mag veel meer kwaliteit verwacht worden!

Tja als ik kijk naar MotorsTV die zo'n beetje het zwakste signaal heeft, dan ook nog eens afgeknepen wordt, is het geen wonder dat ik naar pixels ipv racen zit te kijken
terwijl ik daar ook nog extra voor betaal, mag ik dat wel een schande noemen!!

denk dat ik dan ook maar alle drie de extra's (Nieuws/Sport en de discovery's) dan maar laat varen,
kan ik dan mooi de jaarlijkse SKaart heffingen van betalen.... (als dat doorgaat), mijn portmonee is geen bodemloze put tenslotte.

(Satelliet-)aanvoer probleem. Via de satelliet is het net zo matig van kwaliteit. Hoewel bij Sport1 de beeldkwaliteit nogal wisselend is.